Method and system for declarative configuration of user self-registration and log in pages and processes for a service provider and automatic deployment of the same

ABSTRACT

Methods and systems are provided for configuring an interview-based log in process and a corresponding interview-based log in page for a particular service provider. A graphical user interface (GUI) is displayed at a user system of an administrator. The GUI includes a plurality of options for configuring different interview-based log in processes and corresponding interview-based log in pages for that particular service provider. The administrator to configure the interview-based log in process and the corresponding interview-based log in page for deployment. The administrator can specify a type of log in prompt to define how a user is identified and looked-up, and a type of authentication mechanism to define how the user will be authenticated for the service provider. The type of log in prompt and the type authentication mechanism can be one of a plurality of different types that can be specified by the administrator.

TECHNICAL FIELD

Embodiments of the subject matter described herein relate generally tocloud-based computing and deployment of user self-registration pages andprocesses and log in pages and processes for service providers. Moreparticularly, embodiments of the subject matter relate to methods andsystems for declaratively configuring user self-registration pages andprocesses, and log in pages and processes, for service providers andautomatic deployment of such user self-registration pages and processesand log in pages and processes.

BACKGROUND

Today many enterprises now use cloud-based computing platforms thatallow services and data to be accessed over the Internet (or via othernetworks). Infrastructure providers of these cloud-based computingplatforms offer network-based processing systems that often supportmultiple enterprises (or tenants) using common computer hardware anddata storage. This “cloud” computing model allows applications to beprovided over a platform “as a service” supplied by the infrastructureprovider. The infrastructure provider typically abstracts the underlyinghardware and other resources used to deliver a customer-developedapplication so that the customer no longer needs to operate and supportdedicated server hardware. The cloud computing model can often providesubstantial cost savings to the customer over the life of theapplication because the customer no longer needs to provide dedicatednetwork infrastructure, electrical and temperature controls, physicalsecurity and other logistics in support of dedicated server hardware.

Multi-tenant cloud-based architectures have been developed to improvecollaboration, integration, and community-based cooperation betweencustomer tenants without compromising data security. Generally speaking,multi-tenancy refers to a system where a single hardware and softwareplatform simultaneously supports multiple organizations or tenants froma common data storage element (also referred to as a “multi-tenantdatabase”). The multi-tenant design provides several advantages overconventional server virtualization systems. First, the multi-tenantplatform operator can often make improvements to the platform based uponcollective information from the entire tenant community. Additionally,because all users in the multi-tenant environment execute applicationswithin a common processing space, it is relatively easy to grant or denyaccess to specific sets of data for any user within the multi-tenantplatform, thereby improving collaboration and integration betweenapplications and the data managed by the various applications. Themulti-tenant architecture therefore allows convenient and cost-effectivesharing of similar application feature software between multiple sets ofusers.

A cloud-based computing environment can include a number of differentdata centers, and each data center can include a number of instances,where each instance can support many tenants (e.g., 10,000 tenants ormore). As such, large numbers of tenants can be grouped together intoand share an instance as tenants of that instance. Each tenant is itsown organization (or org) that is identified by a unique identifier (ID)that represents that tenant's data within an instance.

Consumers may use computer network systems, such as the Internet, toaccess a variety of data, applications, services, and other resources.Prior to allowing a user to access system resources, an authenticationprocedure is often employed to reliably verify the identity of the user.For example, passwords may be used for user authentication to prove anidentity and/or to gain access to a protected resource. For instance,during a log in process a user may send a username and password to aremote server or server system in order to authenticate the user foraccess to resources provided by that server system. Even more generally,a username and password may be used to control access to protectedcomputing devices, operating systems, applications (e.g., email, websites, etc.), databases, networks, etc.

The password has long been a thorn in the side of users andorganizations alike, and it is also the root of many serious and costlyproblems. Password-based authentication can be somewhat cumbersome tothe user because having to remember and manage multiple passwords formultiple applications or services is difficult. For example, eachresource typically requires its users to have unique usernames. A usermay be required to remember several different usernames in order toaccess different resources. A user has to keep track of which usernamewas used to set up the account for each resource. Likewise, eachresource may have different rules as to the types of character stringsthat may be used as passwords (e.g., a particular number of characters,a combination of alphabetic and numeric characters, at least one specialcharacter (such as !, @, #, $, %, &, etc.). Thus, in addition toremembering different usernames, a user may also be required to rememberseveral different passwords in order to access different resources, andalso keep track of which username-password pair applies to each account.As a result, users often use simple passwords and/or reuse the samepassword across multiple services and that can negatively impactsecurity. Weak, default, or stolen credentials are often involved in orthe cause of data breaches.

To improve security, organizations often require stronger passwordcomplexity and more frequent changes, but this often leads to poor usersecurity practices, such as writing passwords down or using the samepassword for multiple applications, and increased costs because usersforget their passwords and have to call for resets. In addition, theservice provider in a particular organization that has the poorestsecurity controls becomes the weakest link, and if this service providergets compromised (or any other service provider), the credentials to allthe other service providers get compromised too. Organizations also loseproductivity when users use passwords to log in separately to multipleapplications each day to do their jobs. Many organizations feel theyhave to sacrifice security for user convenience. From a securityperspective, password-based authentication may be vulnerable to certaintypes of attacks or other security issues in addition to problemsassociated with remembering and keeping track of different usernames andpassword combinations for different accounts.

As password-based authentication has become more susceptible to beingcompromised in recent years, interview-based authentication solutions(e.g., passwordless authentication solutions) have recently beendeveloped that aim to eliminate authentication vulnerabilities. Today,some Internet websites or service providers implement some form ofpasswordless log in that allow their users to log in without a password,often by sending a one-time-password over email or SMS to the end userwhen user tries to log in. Examples of passwordless authentication caninclude Touch ID, push notifications, onetime passcodes, etc.Passwordless authentication is not only more secure, but easier,friendlier, and faster than traditional password-based authenticationsolutions.

In a multi-tenant environment, each tenant is tasked with implementingproprietary solutions for user self-registration log in and deployingthose solutions to end users. Moreover, within a single tenant, eachservice provider may also be tasked with implementing proprietarysolutions for user self-registration and log in and deploying thosesolutions to end users. This process can be very time-consuming for eachservice provider of a particular application or service. For example,one drawback is that the process of setting up user self-registrationand log in functionality is very complex, unique and relatively staticonce it is set up and defined. Each implementation requires lots of setup and coding that has to be specific to that implementation and theunderlying technology involved. For example, a text or SMS passwordlesslog in solution would require completely different set up and coding incomparison to an email-based passwordless log in solution. The processof implementing proprietary solutions for user self-registration and login is not only very time-consuming, but inefficient in the event theservice provider wants to provide users with multiple different userself-registration and log in options. This would require completelydifferent set up and coding for each implementation.

BRIEF DESCRIPTION OF THE DRAWINGS

A more complete understanding of the subject matter may be derived byreferring to the detailed description and claims when considered inconjunction with the following figures, wherein like reference numbersrefer to similar elements throughout the figures.

FIG. 1 is a schematic block diagram of an example of a multi-tenantcomputing environment in which features of the disclosed embodiments canbe implemented in accordance with the disclosed embodiments.

FIG. 2 is a block diagram of a system in accordance with the disclosedembodiments.

FIG. 3 illustrates a non-limiting example of a graphical user interfacethat is displayed at a user system of the administrator of a particularservice provider for configuring or setting up a user self-registrationprocess and page for that particular service provider in accordance withthe disclosed embodiments.

FIG. 4 is a flow chart that illustrates an exemplary method forconfiguring or setting up a user self-registration process and page fora particular service provider in accordance with the disclosedembodiments.

FIG. 5 illustrates a non-limiting example of a graphical user interfacethat is displayed at a user system of the administrator of a particularservice provider for configuring or setting up an interview-based log inprocess and page for that particular service provider in accordance withthe disclosed embodiments.

FIG. 6 is a flow chart that illustrates an exemplary method forconfiguring or setting up an interview-based log in process for aparticular service provider in accordance with the disclosedembodiments.

FIG. 7 is a table that illustrates non-limiting examples of differentimplementations of configurable log in capability that have beencustomized for different service providers in accordance with thedisclosed embodiments.

FIG. 8 shows a block diagram of an example of an environment in which anon-demand database service can be used in accordance with someimplementations.

FIG. 9 shows a block diagram of example implementations of elements ofFIG. 8 and example interconnections between these elements according tosome implementations.

FIG. 10A shows a system diagram illustrating example architecturalcomponents of an on-demand database service environment according tosome implementations.

FIG. 10B shows a system diagram further illustrating examplearchitectural components of an on-demand database service environmentaccording to some implementations.

FIG. 11 illustrates a diagrammatic representation of a machine in theexemplary form of a computer system within which a set of instructions,for causing the machine to perform any one or more of the methodologiesdiscussed herein, may be executed.

DETAILED DESCRIPTION

It would be desirable to simplify and automate the process of setting upa user self-registration page and a log in page so that it can be easilycustomized for different service providers who offer applications orservices via a multi-tenant cloud-based platform. It would also bedesirable to provide a solution that makes it easy to build and deployuser self-registration and log in processes without requiringdevelopment of a proprietary solution for each service provider.

The exemplary embodiments presented here relate to systems, methods,procedures, and technology for declaratively configuring log in pagesand processes for service providers and automatic deployment of such login pages and processes, and their associated user self-registrationpages and processes. The disclosed embodiments can be used, for example,by administrators of many different service providers (e.g., of aparticular organization/tenant) for configuring setup of userself-registration and interview-based log in capability that iscustomized for their respective service providers. For example, in someimplementations, the disclosed embodiments can provide a declarativeUI-based system that allows administrators for different serviceproviders (e.g., administrators for different organizations or tenantsof a multi-tenant system) to set up their own customizedself-registration process and/or customized interview-based log insolution (e.g., a passwordless log in solution) for users who want toaccess or interact with applications or services provided by thatservice provider (e.g., services provided by an organization/tenant viaa cloud computing platform). In other words, each administrator canutilize the disclosed technologies to automate the processes of (1)setting up a self-registration process for that service provider, and/or(2) setting up an interview-based log in solution for that serviceprovider. As will be described below, in accordance with the disclosedembodiments, an administrator can select a type of user credential, andan option for self-registration verification process, that could belinked to the type of user credential, or could be separate from thetype of user credential depending on the implementation. Theself-registration verification process allows the user credentialentered at the prompt presented at the corresponding userself-registration page to be verified. Similarly, an administrator canspecify a type of log in prompt, and an authentication mechanism thatcan include one or more of: commonly used authentication techniques,verification processes including verification challenges, etc. Thedisclosed embodiments can eliminate the need for an intensive set up andcoding effort (e.g., manual creation of user interfaces and usermapping) that would normally be needed to provide a log in solution andassociated self-registration process that can be customized for eachservice provider. For example, the disclosed embodiments can allow eachorganization or tenant (e.g., same underling data partition) to easilyimplement different logic to allow for multiple setups for different login pages and processes for different service providers (e.g.,sub-divisions of that single organization or tenant) and theirassociated self-registration pages and processes.

Prior to describing an exemplary embodiment with reference to thedrawings, certain terminology will be defined.

As used herein, the term “multi-tenant database system” refers to thosesystems in which various elements of hardware and software of thedatabase system may be shared by one or more tenants. For example, agiven application server may simultaneously process requests for a greatnumber of tenants, and a given database table may store rows for apotentially much greater number of tenants. In a multitenantarchitecture, a number of tenants share IT resources such as databaseservers, application servers, and infrastructure required to runapplications, resulting in an environment where resources are managedcentrally.

A cloud-based computing environment can include a number of differentdata centers. Each data center can include a number of instances. Eachinstance can support many (e.g., 10,0000) tenants, where each tenant hastheir own organization (or org).

An instance (also known as a point of deployment (POD)) is a cluster ofsoftware and hardware represented as a single logical server that hostsmultiple organization's data and runs their applications. An instancecan be a self-contained unit that contains all that is required to runan instance including the application server, database server, databaseitself, search and file system. Large numbers of tenants, for example,10,000, can be grouped together into and share an instance as tenants ofthat instance. A platform as a service (PaaS), such as the Force.complatform, can run on multiple instances, but data for any singleorganization is always stored on a single instance where their dataresides. Each tenant is allocated to one and only one instance (or POD)and that is where their data resides. As such, an instance refers to asingle logical server that multiple organizations live on as tenants. Aninstance can be identified in a URL by a region and a server number. Forexample, if it is assumed that there are currently 21 instances in NorthAmerica, in the URL na8.salesforce.com, nab can refer to particularserver, where na refers to the general location of the server (NorthAmerica) and 8 refers to the serverID within that general location(server 8 of 21 in North America).

An organization or “org” can be thought of as a logical container forone cohesive set of related data, metadata, configurations, settings andschemas that is separate from that of all other organizations. Eachorganization has or is associated with a unique identifier (ID) thatrepresents a tenant's data within an instance. Each identifier defines avirtual or logical space provided to an individual tenant (e.g., adefined set of users) where all of that tenant's data and applicationsare stored within an instance so that it is separate from that of allother organizations that are part of that instance. Each uniqueidentifier serves as the access key and security barrier for anindividual tenant's data in the system. As such, each organization canbe identified by its own unique identifier that allows thatorganization's data to be separated from data of other organizations.Even though all tenants within an instance share the same database, theorganization's unique identifier is stored in every table to ensure thatevery row of data is linked back to the correct tenant and the data fromother tenants sharing the same instance cannot be mixed up. Eachorganization can have its own custom content that is unique to thatparticular organization. For a particular organization, custom contentcan include metadata and associated data that is unique to thatparticular organization. Each organization can have custom fields,custom objects, workflows, data sharing rules, visual force pages andapex coding, etc. As such, each organization can be highly customizedwith respect to other organizations that are part of the same instance.

An environment is an organization used for a specific purpose. Anorganization can be used as a production environment unless it is housedon a sandbox instance, in which case the organization can be used fordevelopment, testing, integration, training or other non-productionpurposes. For example, tenants may have an organization is used as aproduction environment, another organization used for a developmentenvironment, another organization used for testing environment, anotherorganization used for integration environment, another organization usedfor their training environment.

The terms “self-registration” or “sign up” as used herein can refer toself-registration processes involved in registering with or subscribingto an application or service, joining a network, creating an account,etc.

The term “log in” (or log on or sign in or sign on) can all refer toprocesses by which an individual gains access to a computer system byidentifying and authenticating themselves by presenting appropriatecredentials. In practice, modern secure systems also often require asecond factor for extra security. As such, the terms “log in,” “log on,”“sign in,” and “sign on”) can be used interchangeably herein to refer,for example, to the act of logging into a web-based application orservice that is served by a server system, the act of logging into aremote or networked computer system, the act of logging into a database,the act of logging into a mobile device, the act of logging into acomputer, such as a multiuser computer, etc.

As used herein, a “verification process” can refer to a process that isused to verify or confirm something about a user. For example, in thecontext of a user self-registration process, a verification process canrefer to a process that is used to create an identity for a registrantwithin a system that allows that registrant to become registered withthe system, and verify that the registrant's credentials are valid. Forexample, in a user self-registration process, a user can confirm that auser credential (e.g., phone number or email) they are providing istheirs. In other words, the user is verifying/confirming/authenticatingthat a user credential they are providing, which is tied to the user'sidentity, is correct. By contrast, in the context of a user log inprocess, a verification process can refer to a process that is used toconfirm identity of a user that is trying to log in to a system, and caninclude authentication mechanisms including identity verificationchallenge protocols. For example, in the context of a user log inprocess, a phone, email, or a redirection to a third-party identityprovider (IdP) can be used to authenticate a user. Thus, theverification process can verify who the user is via somepreviously-known mechanism (e.g., Facebook API results, a pin sent to amobile phone number, etc.).

FIG. 1 is a schematic block diagram of an example of a multi-tenantcomputing environment in which features of the disclosed embodiments canbe implemented in accordance with the disclosed embodiments. As shown inFIG. 1, an exemplary cloud-based solution may be implemented in thecontext of a multi-tenant system 100 including a server 102 thatsupports applications 128 based upon data 132 from a database 130 thatmay be shared between multiple tenants, organizations, or enterprises,referred to herein as a multi-tenant database. Data and servicesgenerated by the various applications 128 are provided via a network 145to any number of user systems 140, such as desktops, laptops, tablets,smartphones or other client devices, Google Glass™, and any othercomputing device implemented in an automobile, aircraft, television, orother business or consumer electronic device or system, including webclients.

Each application 128 is suitably generated at run-time (or on-demand)using a common application platform 110 that securely provides access tothe data 132 in the database 130 for each of the various tenantorganizations subscribing to the system 100. In accordance with onenon-limiting example, the service cloud 100 is implemented in the formof an on-demand multi-tenant customer relationship management (CRM)system that can support any number of authenticated users for aplurality of tenants.

As used herein, a “tenant” or an “organization” should be understood asreferring to a group of one or more users (typically employees) thatshares access to common subset of the data within the multi-tenantdatabase 130. In this regard, each tenant includes one or more usersand/or groups associated with, authorized by, or otherwise belonging tothat respective tenant. Stated another way, each respective user withinthe multi-tenant system 100 is associated with, assigned to, orotherwise belongs to a particular one of the plurality of enterprisessupported by the system 100.

Each enterprise tenant may represent a company, corporate department,business or legal organization, and/or any other entities that maintaindata for particular sets of users (such as their respective employees orcustomers) within the multi-tenant system 100. Although multiple tenantsmay share access to the server 102 and the database 130, the particulardata and services provided from the server 102 to each tenant can besecurely isolated from those provided to other tenants. The multi-tenantarchitecture therefore allows different sets of users to sharefunctionality and hardware resources without necessarily sharing any ofthe data 132 belonging to or otherwise associated with otherorganizations.

The multi-tenant database 130 may be a repository or other data storagesystem capable of storing and managing the data 132 associated with anynumber of tenant organizations. The database 130 may be implementedusing conventional database server hardware. In various embodiments, thedatabase 130 shares processing hardware 104 with the server 102. Inother embodiments, the database 130 is implemented using separatephysical and/or virtual database server hardware that communicates withthe server 102 to perform the various functions described herein.

In an exemplary embodiment, the database 130 includes a databasemanagement system or other equivalent software capable of determining anoptimal query plan for retrieving and providing a particular subset ofthe data 132 to an instance of application (or virtual application) 128in response to a query initiated or otherwise provided by an application128, as described in greater detail below. The multi-tenant database 130may alternatively be referred to herein as an on-demand database, inthat the database 130 provides (or is available to provide) data atrun-time to on-demand virtual applications 128 generated by theapplication platform 110, as described in greater detail below.

In practice, the data 132 may be organized and formatted in any mannerto support the application platform 110. In various embodiments, thedata 132 is suitably organized into a relatively small number of largedata tables to maintain a semi-amorphous “heap”-type format. The data132 can then be organized as needed for a particular virtual application128. In various embodiments, conventional data relationships areestablished using any number of pivot tables 134 that establishindexing, uniqueness, relationships between entities, and/or otheraspects of conventional database organization as desired. Further datamanipulation and report formatting is generally performed at run-timeusing a variety of metadata constructs. Metadata within a universal datadirectory (UDD) 136, for example, can be used to describe any number offorms, reports, workflows, user access privileges, business logic andother constructs that are common to multiple tenants.

Tenant-specific formatting, functions and other constructs may bemaintained as tenant-specific metadata 138 for each tenant, as desired.Rather than forcing the data 132 into an inflexible global structurethat is common to all tenants and applications, the database 130 isorganized to be relatively amorphous, with the pivot tables 134 and themetadata 138 providing additional structure on an as-needed basis. Tothat end, the application platform 110 suitably uses the pivot tables134 and/or the metadata 138 to generate “virtual” components of thevirtual applications 128 to logically obtain, process, and present therelatively amorphous data 132 from the database 130.

The server 102 may be implemented using one or more actual and/orvirtual computing systems that collectively provide the dynamicapplication platform 110 for generating the virtual applications 128.For example, the server 102 may be implemented using a cluster of actualand/or virtual servers operating in conjunction with each other,typically in association with conventional network communications,cluster management, load balancing and other features as appropriate.The server 102 operates with any sort of conventional processinghardware 104, such as a processor 105, memory 106, input/output features107 and the like. The input/output features 107 generally represent theinterface(s) to networks (e.g., to the network 145, or any other localarea, wide area or other network), mass storage, display devices, dataentry devices and/or the like.

The processor 105 may be implemented using any suitable processingsystem, such as one or more processors, controllers, microprocessors,microcontrollers, processing cores and/or other computing resourcesspread across any number of distributed or integrated systems, includingany number of “cloud-based” or other virtual systems. The memory 106represents any non-transitory short or long-term storage or othercomputer-readable media capable of storing programming instructions forexecution on the processor 105, including any sort of random accessmemory (RAM), read only memory (ROM), flash memory, magnetic or opticalmass storage, and/or the like. The computer-executable programminginstructions, when read and executed by the server 102 and/or processor105, cause the server 102 and/or processor 105 to create, generate, orotherwise facilitate the application platform 110 and/or virtualapplications 128 and perform one or more additional tasks, operations,functions, and/or processes described herein. It should be noted thatthe memory 106 represents one suitable implementation of suchcomputer-readable media, and alternatively or additionally, the server102 could receive and cooperate with external computer-readable mediathat is realized as a portable or mobile component or platform, e.g., aportable hard drive, a USB flash drive, an optical disc, or the like.

The application platform 110 is any sort of software application orother data processing engine that generates the virtual applications 128that provide data and/or services to the user systems 140. In a typicalembodiment, the application platform 110 gains access to processingresources, communications interfaces and other features of theprocessing hardware 104 using any sort of conventional or proprietaryoperating system 108. The virtual applications 128 are typicallygenerated at run-time in response to input received from the usersystems 140. For the illustrated embodiment, the application platform110 includes a bulk data processing engine 112, a query generator 114, asearch engine 116 that provides text indexing and other searchfunctionality, and a runtime application generator 120. Each of thesefeatures may be implemented as a separate process or other module, andmany equivalent embodiments could include different and/or additionalfeatures, components or other modules as desired.

The runtime application generator 120 dynamically builds and executesthe virtual applications 128 in response to specific requests receivedfrom the user systems 140. The virtual applications 128 are typicallyconstructed in accordance with the tenant-specific metadata 138, whichdescribes the particular tables, reports, interfaces and/or otherfeatures of the particular application 128. In various embodiments, eachvirtual application 128 generates dynamic web content that can be servedto a browser or other client program 142 associated with its user system140, as appropriate.

The runtime application generator 120 suitably interacts with the querygenerator 114 to efficiently obtain multi-tenant data 132 from thedatabase 130 as needed in response to input queries initiated orotherwise provided by users of the user systems 140. In a typicalembodiment, the query generator 114 considers the identity of the userrequesting a particular function (along with the user's associatedtenant), and then builds and executes queries to the database 130 usingsystem-wide metadata 136, tenant specific metadata 138, pivot tables134, and/or any other available resources. The query generator 114 inthis example therefore maintains security of the common database 130 byensuring that queries are consistent with access privileges granted tothe user and/or tenant that initiated the request.

With continued reference to FIG. 1, the data processing engine 112performs bulk processing operations on the data 132 such as uploads ordownloads, updates, online transaction processing, and/or the like. Inmany embodiments, less urgent bulk processing of the data 132 can bescheduled to occur as processing resources become available, therebygiving priority to more urgent data processing by the query generator114, the search engine 116, the virtual applications 128, etc.

In exemplary embodiments, the application platform 110 is utilized tocreate and/or generate data-driven virtual applications 128 for thetenants that they support. Such virtual applications 128 may make use ofinterface features such as custom (or tenant-specific) screens 124,standard (or universal) screens 122 or the like. Any number of customand/or standard objects 126 may also be available for integration intotenant-developed virtual applications 128. As used herein, “custom”should be understood as meaning that a respective object or applicationis tenant-specific (e.g., only available to users associated with aparticular tenant in the multi-tenant system) or user-specific (e.g.,only available to a particular subset of users within the multi-tenantsystem), whereas “standard” or “universal” applications or objects areavailable across multiple tenants in the multi-tenant system.

The data 132 associated with each virtual application 128 is provided tothe database 130, as appropriate, and stored until it is requested or isotherwise needed, along with the metadata 138 that describes theparticular features (e.g., reports, tables, functions, objects, fields,formulas, code, etc.) of that particular virtual application 128. Forexample, a virtual application 128 may include a number of objects 126accessible to a tenant, wherein for each object 126 accessible to thetenant, information pertaining to its object type along with values forvarious fields associated with that respective object type aremaintained as metadata 138 in the database 130. In this regard, theobject type defines the structure (e.g., the formatting, functions andother constructs) of each respective object 126 and the various fieldsassociated therewith.

Still referring to FIG. 1, the data and services provided by the server102 can be retrieved using any sort of personal computer, mobiletelephone, tablet or other network-enabled user system 140 on thenetwork 145. In an exemplary embodiment, the user system 140 includes adisplay device, such as a monitor, screen, or another conventionalelectronic display capable of graphically presenting data and/orinformation retrieved from the multi-tenant database 130, as describedin greater detail below.

Typically, the user operates a conventional browser application or otherclient program 142 executed by the user system 140 to contact the server102 via the network 145 using a networking protocol, such as thehypertext transport protocol (HTTP) or the like. The user typicallyauthenticates his or her identity to the server 102 to obtain a sessionidentifier (“SessionID”) that identifies the user in subsequentcommunications with the server 102. In some cases, to authenticate, theuser can enter a client identifier and credential, such as a password.In some cases where users have many different log in credentials toremember for other systems, it can be difficult for the user to remembertheir password, username, or client identifier. To help make this log inprocess easier, many applications and services have developed“passwordless” authentication mechanisms. Passwordless authentication isnot only more secure, but easier, friendlier, and faster thantraditional password-based authentication solutions.

Examples of passwordless authentication mechanisms can include Touch ID,push notifications, or onetime passcodes. For instance, one widely usedpasswordless authentication mechanism is Auth0. In one form ofpasswordless authentication with Auth0, the user is asked to enter theiremail address. Once the user submits the email address, a unique tokenor code is created and stored. An email with a URL that contains theunique token will be generated and sent to the user. When the link isclicked by the user, a server verifies that the unique token is validand exchanges it for a long-lived session or token, which is stored inyour database and sent back to the client to be stored typically as abrowser cookie. There are also be checks on the server to ensure thatthe link was clicked within a certain period, e.g., three minutes. Inanother form of passwordless authentication with Auth0, the user isrequested to enter their email address. An email is sent to the userwith a unique onetime code. Once the user enters this code into anapplication, the application validates that the code is correct, asession is initiated and the user is logged in. In yet another form ofpasswordless authentication with Auth0, the user is asked to enter avalid phone number. A unique onetime code is then sent to the phonenumber via SMS. Once the user enters this code into an application, theapplication validates that the code is correct and that the phone numberexists and belongs to a user, a session is initiated, and the userlogged in. In still another form of passwordless authentication withAuth0, the user is asked to place their finger on a mobile device. Aunique key pair is generated on the device and a new user is created onthe server that maps to the key. A session is initiated and the user islogged in. This is often referred to as Touch ID.

When the identified user requests access to a virtual application 128,the runtime application generator 120 suitably creates the applicationat run time based upon the metadata 138, as appropriate. However, if auser chooses to manually upload an updated file (through either theweb-based user interface or through an API), it will also be sharedautomatically with all of the users/devices that are designated forsharing.

As noted above, the virtual application 128 may contain Java, ActiveX,or other content that can be presented using conventional clientsoftware running on the user system 140; other embodiments may simplyprovide dynamic web or other content that can be presented and viewed bythe user, as desired. As described in greater detail below, the querygenerator 114 suitably obtains the requested subsets of data 132 fromthe database 130 as needed to populate the tables, reports or otherfeatures of the particular virtual application 128. In variousembodiments, application 128 embodies the functionality of acollaboration solution such as the Chatter system, described below.

FIG. 2 is a block diagram of a cloud-based computing platform 200 inaccordance with the disclosed embodiments. The cloud-based computingplatform 200 is a system (e.g., cloud-based server system such as thatin FIG. 1) that can be shared by many different organizations, andhandles the storage of, and access to, different metadata, objects, dataand applications across disparate organizations. In one embodiment, thecloud-based computing platform 200 can be part of a database system,such as a multi-tenant database system. The cloud-based computingplatform 200 is configured to handle requests for any user associatedwith any organization that is a tenant of the system. Although notillustrated, the cloud-based computing platform 200 can include othercomponents such as a system database, one or more processing systemsthat execute applications, process space where the application runs, andprogram code that will be described in greater detail below.

The cloud-based computing platform 200 includes a connectivity engine225 serves as a network interface that allows users of user systems 212to establish a communicative connection to the cloud-based computingplatform 200 over a network (not illustrated in FIG. 2) such as theInternet or any type of network described herein. This allows thevarious user systems 212 to connect to application platform 200. In oneembodiment, the connectivity engine 225 can include an OAuth generatorthat provides organization tokens for a particular session. OAuth is anopen standard for authorization that provides to clients a securedelegated access to server resources on behalf of a resource owner.OAuth standards specify a process for resource owners to authorizeaccess to their server resources without sharing their credentials.OAuth allows access tokens to be issued to clients by an authorizationserver, with the approval of the resource owner. The client can then usethe access token to access the protected resources hosted by theresource server.

The cloud-based computing platform 200 includes an application platform210 and various user systems 212 that access various applications andservices provided by the application platform 210. The applicationplatform 210 is a cloud-based user interface. For example, theapplication platform 210 can be a software as a service (SaaS) platformin one non-limiting embodiment. The application platform 210 has accessto one or more database systems 230 that store information (e.g., dataand metadata) for a number of different organizations 250-1, 250-2, . .. 250-n including user information, organization information, custominformation, etc. The database systems 230 can include a multi-tenantdatabase system 130 as described with reference to FIG. 1, as well asother databases or sources of information that are external to themulti-tenant database system 130 of FIG. 1.

In one embodiment, the multi-tenant database system 130 can store datain the form of records and customizations. As used herein, the term“record” refers to an instance of a data object created by a user of adatabase service, for example, about a particular (actual or potential)business relationship or project. The data object can have a datastructure defined by the database service (a standard object) or definedby a subscriber (custom object). For example, a record can be for abusiness partner or potential business partner (e.g. a client, vendor,distributor, etc.) of the user, and can include an entire company,subsidiaries, or contacts at the company. As another example, a recordcan be a project that the user is working on, such as an opportunity(e.g. a possible sale) with an existing partner, or a project that theuser is trying to get. In one embodiment implementing a multi-tenantdatabase, all of the records for the tenants have an identifier storedin a common table. A record has data fields that are defined by thestructure of the object (e.g. fields of certain data types andpurposes). A record can also have custom fields defined by a user. Afield can be another record or include links thereto, thereby providinga parent-child relationship between the records. Customizations caninclude custom database objects and fields, Apex Code, Visualforce,Workflow, etc.

In the example illustrated in FIG. 2, only three organizations 250-1,250-2, 250-n are illustrated for sake of simplicity, but it should beappreciated that the computing platform 200 can provide applications andservices and store data for any number of organizations. In other words,the n in 250-n can be any number. Each organization 250 can be thoughtof as a logical container for one cohesive set of related data,metadata, configurations, settings and schemas that is separate fromthat of all other organizations. Each organization 250 is illustrated inFIG. 2 using dotted-line boxes within the database system(s) 230 torepresent that they are a logical boundary that logically segregatesdata and access to the data by a particular tenant. Although theorganizations 250 are part of the same instance and share commoninfrastructure, each organization 250 has or is associated with a uniqueidentifier (ID) that represents a tenant's data within an instance, anddefines a virtual or logical space provided to an individual tenant(e.g., a defined set of users) where all of that tenant's data andapplications are stored within an instance so that it is separate fromthat of all other organizations that are part of that instance. In thisregard, the unique identifier for each organization serves as the accesskey and security barrier for an individual tenant's data in the system,and thus allows that organization's data to be separated from data ofother organizations even though all tenants within an instance share thesame database. The unique identifier for a particular organization isstored in every table to ensure that every row of data is linked back tothe correct tenant and the data from other tenants sharing the sameinstance cannot be mixed up.

Each organization 250 is a source of metadata and data associated withthat metadata that collectively make up an application or service. Eachorganization can have its own custom content that is unique to thatparticular organization, and can be highly customized with respect toother organizations that are part of the same instance. For a particularorganization, custom content can include metadata and associated datathat is unique to that particular organization. In one implementation,the metadata can include customized content of the organization 250-1(e.g., customizations done to an instance that define business logic andprocesses for an organization). Some non-limiting examples of metadatacan include, for example, customized content that describes a build andfunctionality of objects (or tables), tabs, fields (or columns),permissions, classes, pages (e.g., Apex pages), triggers, controllers,sites, communities, workflow rules, data sharing rules, automation rulesand processes, etc. Data is associated with metadata to create anapplication or service. Data can be stored as one or more objects, whereeach object holds particular records for an organization. As such, datacan include records (or user content) that are held by one or moreobjects.

Based on a user's interaction with a user system 212, the applicationplatform 210 accesses an organization's data (e.g., records held by anobject) and metadata that is stored at one or more database systems 230,and provides the user system 212 with access to applications (orservices) based on that data and metadata.

As such, different organizations or tenants of organizations can use theapplication platform 210 to provide resources (e.g., applications andservices) that are potentially accessible by end users who havesuccessfully registered with and authenticated to allow them access tothose resources. The various user systems 212-2 . . . 212-4 can accessresources (e.g., interact with web pages, applications or services)provided by the cloud-based computing platform 200 so long as they havebeen granted access privileges. These resource providers can be referredto herein as “service providers.” Each service provider may havedifferent wants in terms of how their self-registration pages andprocesses are configured. Similarly, each service provider may havedifferent wants in terms of how their log in pages and processes areconfigured.

In accordance with the disclosed embodiments, administrators for eachservice provider can declaratively configure, via the graphical userinterface, a customized page and a corresponding customized process forthat particular service provider, and deploy the customized page and thecorresponding customized process to users via the application platform.In other words, any administrator of a particular service provider(e.g., a particular organization or tenant) can utilize a control panel214-1 of their user system 212-1 to configure a process and a page for aparticular service provider. For example, an administrator can accessthe application platform 210 via user system 212-1 to configure anddeploy user registration pages/processes and interview-based log inpages/processes for any end users that desire access to applications orservices offered by a service provider via the application platform 210.In accordance with the disclosed embodiments, user registrationpages/processes and log in pages/processes can be configured to have adifferent handling for every end user. For instance, user A and B willsee/access the same sign in page in order to log in into a serviceprovider. However, user A could be challenged with email-based OTP,whereas user B could be challenged with SMS-based OTP. This differencein decision making regarding the log in page and process (andcorresponding registration page and process) can be configured by anadministrator. A code repository 270 stores the code used to implementthe registration and log in processing and build associated pages. Inone embodiment, the code repository 270 can be an applicationserver/service that handles integration with other services that areinvolved in passwordless login. For example, the code repository caninclude a module that is responsible for sending text messages thatinclude the identity verification code, another module that isresponsible for sending identity verification code via email, anothermodule that is responsible for sending a push notification with averification request, etc. The code repository 270 can be accessed bythe user registration configuration module 226 to retrieve code forbuilding registration and log in pages with built in logic for acorresponding registration or log in process that are customized to meettheir specific needs/requirements. An administrator can use the userregistration configuration module 226 to configure and deploy aregistration page and corresponding registration process for aparticular service provider that is customized to meet their specificneeds/requirements, and can use the log in configuration module 228 toconfigure and deploy a log in page and a corresponding log in processfor that particular service provider that is customized to meet theirspecific needs/requirements. The registration and log in pages andcorresponding registration and log in processes can be built byretrieving selected code from the code repository 270 based on inputs bythe administrator. Based on information input by the administrator, theuser registration configuration module 226 and the log in configurationmodule 228 can then automatically build registration and log in pageswith specified processing features, and also execute processing toexecute the corresponding registration and log in processes and thevarious verification methodologies described herein. To facilitateimplementation any of the embodiments described herein, the applicationplatform 210 and/or code repository 270 can be integrated with theexternal services 280 for verification, such as email delivery services282, text/SMS delivery services 284, push notification services 286, orany other known external services 280 that can be used for verification,such as a third party identity provider or verification service, etc.

In general, an administrator can interact with a graphical userinterface of the control panel to select one of a plurality of optionsfor configuring different processes and pages for that particularservice provider. For example, the administrator can interact with a GUIelement to select one of the options to configure the process and thepage. After selecting that option, the administrator can interact withanother GUI element to specify a type of identifier associated with auser to be verified as part of the process for that particular serviceprovider. The type of identifier is one of a plurality of differenttypes of identifiers that can be specified by the administrator. Theadministrator can also interact with another GUI element to specify atype of verification process (e.g., a type or self-registrationverification process or type of authentication mechanism to be used toauthenticate user(s) during log in), such as, a type of identityverification challenge to define how the user will be verified) as partof the process for the service provider. The type of verificationprocess is one of a plurality of different types of verificationprocesses that can be specified by the administrator that allows theuser credential entered at the prompt presented at the correspondinguser self-registration page to be verified. An appropriate module 226,228 at the application platform 210 can receive the inputs from theadministrator can process them to automatically generate the page basedon the administrator's inputs and selections.

As an example, when a user seeks to register for access to a resourceprovided by the particular service provider, module 226 at theapplication platform 210 can deploy the page (e.g., in response to arequest from the user). For example, for a self-registration process,the page can allow a user to register as a user. Likewise, for a log inprocess, the page can allow the user to request access to a resource(e.g., a web site, an application or a service) offered by thatparticular service provider via the application platform 210 (assumingthe log process is successfully completed by the user). The pageincludes features and logic for the process that have been customizedfor that particular service provider.

To configure the self-registration page/process, the administrator canselect a user self-registration setup option to configure a userself-registration process and a corresponding user self-registrationpage for deployment by that particular service provider. Theadministrator can specify a user credential (e.g., email address,telephone number, or any other unique identifier for communication meansassociated with the user) that defines how the user will contacted tocomplete the user self-registration process. In one embodiment, theadministrator can specify the type of verification process to define howthe user will be verified as part of the user self-registration processfor the service provider (e.g., specify an identity verificationchallenge such as verify your email by logging in to a Facebook accountcreated with that email). The verification process is a correspondingself-registration verification process that specifies how a user will beverified as part of the user self-registration process (e.g., afterentering the user credential at a prompt presented at the correspondinguser self-registration page). The corresponding self-registrationverification process can be, for example, a prompt for aone-time-password or passcode sent via text message or via emailmessage, or a redirection to an identity provider. The administrator canalso specify various other features of the self-registration page andprocess, such as, user fields that are to be included to collect userinformation during the user self-registration process (e.g., a firstname of the user, a last name of the user, a username of the user, anemail address of the user, a phone number of the user, and a nickname ofthe user), whether the user is required to set a password as part of theuser self-registration process, user creation information required aspart of the user self-registration process, etc. The corresponding userself-registration page can be used to register for access to any type ofresource such as a web site, an application or a service offered by thatparticular service provider.

To configure the log in page/process, the administrator can select aninterview-based log in option that allows the administrator to configurean interview-based log in process and a corresponding interview-basedlog in page for deployment by that particular service provider. Theadministrator can specify a type of log in prompt to define how the useris identified and looked-up during the interview-based log in processfor the service provider. For example, the type of log in prompt can beconfigured to accept one or more of the following types of identifierinformation for the user: an email address of the user, a telephonenumber of the user, a social security number of the user, or anotherunique identifier information for the user. The administrator can alsospecify the type of authentication mechanism that defines how a userwill be authenticated as part of the interview-based log in process forthe service provider (e.g., after entering their identifier informationat the specified log in prompt). For example, the type of authenticationmechanism can include one or more of: a prompt for a password, or apasswordless authentication mechanism such as a prompt for aone-time-password or passcode sent to the user via text message or viaemail message, a redirection to an identity provider for single sign on(SSO) authentication, and a prompt for a biometric input by the user.The log in page can be to log in for access to any resource provided bythe service provider such as access to a web site, an application or aservice offered by that particular service provider.

After configuration, the application platform 210 can serve aself-registration page for a particular service provider to end users,and the end users can complete the self-registration process that hasbeen configured for that particular service provider. After successfullycompleting the self-registration process, the end users can then accessan interview-based log in page that has been configured for thatparticular service provider and complete a log in process that has beenconfigured for that particular service provider. Any of the end userswho successfully complete the log in process can then access (via usersystems 212-2 . . . 212-4 of end users) protected resources provided viathe application platform 210 for that particular service provider if oruntil the session expires in which case the user would need to re-log in(e.g., using the discovery-based log in option).

Various events or tasks performed by the various elements in FIG. 2 willbe described in greater detail below with reference to FIGS. 3-7. Forexample, certain operations performed at or by the user systems 212, theorganizations 250, the application platform 210, the userself-registration configuration module 226, the log in configurationmodule 228, and the database systems 230 will be described below. Inthat regard, FIGS. 3-7 will be described with continued reference toFIG. 2.

Automated Setup of User Self-Registration Process and Page

FIG. 3 illustrates a graphical user interface that is displayed at auser system of the administrator of a particular service provider forconfiguring or setting up a user self-registration process and page forthat particular service provider in accordance with the disclosedembodiments. FIG. 4 illustrates a method 400 for configuring or settingup a user self-registration process and page for a particular serviceprovider in accordance with the disclosed embodiments. FIG. 4 will bedescribed with reference to certain graphical user interface elementsshown in FIG. 3.

As a preliminary matter, it should be understood that the user interfaceof FIG. 3 and the steps of the method 400 are not necessarily limiting.With reference to method 400, steps can be added, omitted, and/orperformed simultaneously without departing from the scope of theappended claims. It should be appreciated that the method 400 mayinclude any number of additional or alternative tasks, that the tasksshown in FIG. 4 need not be performed in the illustrated order, and thatthe method 400 may be incorporated into a more comprehensive procedureor process having additional functionality not described in detailherein. Moreover, one or more of the tasks shown in FIG. 4 couldpotentially be omitted from an embodiment of the method 400 as long asthe intended overall functionality remains intact. It should also beunderstood that the illustrated method 400 can be stopped at any time.The method 400 is computer-implemented in that various tasks or stepsthat are performed in connection with the method 400 may be performed bysoftware, hardware, firmware, or any combination thereof. Forillustrative purposes, the following description of the method 400 mayrefer to elements mentioned above in connection with FIGS. 1 and 2. Incertain embodiments, some or all steps of this process, and/orsubstantially equivalent steps, are performed by execution ofprocessor-readable instructions stored or included on aprocessor-readable medium. For instance, in the description of FIG. 4that follows, the user systems 212, and the application platform 210will be described as performing various acts, tasks or steps, but itshould be appreciated that this refers to processing system(s) of theseentities executing instructions to perform those various acts, tasks orsteps. Depending on the implementation, some of the processing system(s)can be centrally located, or distributed among a number of serversystems that work together. Furthermore, in the description of FIG. 4, aparticular example is described in which a user of a user systemperforms certain actions by interacting with other elements of thesystem via the user system. Various acts, tasks or steps FIG. 4 will bedescribed below with reference to screenshots shown in FIG. 3.

As shown in FIG. 4, the method 400 begins at 410, where an administratorfor a particular service provider selects a user self-registrationoption to configure the user self-registration process and correspondingweb page. The user self-registration page can be, for example, a userself-registration page for a web site, application or service offered bythat particular service provider. In one embodiment, the userself-registration page can be, for example, a user self-registrationpage for a web site, application or service that is served or providedby the application platform for a particular organization or for aparticular tenant of a particular organization of a cloud-basedmulti-tenant system.

In one embodiment, shown in FIG. 3, the administrator for a particularservice provider can utilize a drop-down menu 302 to select a userself-registration setup option that allows the administrator toconfigure the user self-registration process and corresponding web pagefor deployment by that particular service provider. In one non-limitingembodiment, the user self-registration process is “interview-based”meaning that a user accessing the self-registration page is asked tofill in increasing amounts of information as they proceed through theself-registration process, and the information requested may varydepending on information previously provided.

At 420 of FIG. 4, the administrator for the particular service providercan optionally customize graphical user interface elements and featuresthat are to be displayed as part of the user self-registration page. Asshown in FIG. 3, in one embodiment, the administrator may, if theychoose, specify things such as a background color (via text field 304),logo images (via text field 306), or other graphical user interfaceelements (via other text fields that are not illustrated) that are to bedisplayed as part of the user self-registration page, etc.

At 430, the administrator for the particular service provider can selectwhich user fields are to be included in the user interface of theself-registration page to collect user information during the userself-registration process. In one non-limiting implementationillustrated in FIG. 3, examples of user fields 307 can include firstname of the user, last name of the user, username of the user, emailaddress of the user, phone number of the user, nickname of the user,first name of the user, but many other types of user fields could beincluded depending on the implementation. In this implementation, theadministrator for the particular service provider can check selectedcheck boxes to select which ones of the user fields 307 are to beincluded in the user interface of the self-registration page to collectuser information during the user self-registration process. In thisexample, the administrator has selected all of the user fields that arelisted.

At 440, the administrator for the particular service provider can selectan option to specify whether the user is required to set a password aspart of the user self-registration process. In one non-limitingimplementation illustrated in FIG. 3, the administrator for theparticular service provider can check a check box labeled “CollectPassword” to specify whether the user is required to set a password aspart of the user self-registration process. In this example, theadministrator has selected the “Collect Password” check box.

At 450, the administrator for the particular service provider candeclaratively customize the user self-registration process and the userinterface elements that are used to define the user self-registrationpage for the particular service provider (e.g., for a particularorganization or for a particular tenant of a particular organization).For example, the administrator for the particular service provider canspecify the type of user credential and corresponding self-registrationverification process that specifies how the user is to be verified aspart of the user self-registration process. The administrator canspecify either custom or default options for the type of user credentialand corresponding self-registration verification process.

For example, the administrator can select various options (e.g., usingthe dropdown menu 309 of FIG. 3) to customize the type of usercredential and corresponding self-registration verification process. Byspecifying the type of user credential, the administrator can define howthe user can be contacted to complete the self-registration process.Non-limiting examples of the types of user credentials that can beselected by the admin can include email address, telephone number, orany other unique identifier for communication means associated with theuser. As part of the self-registration process, the user can also beasked to submit other information to complete the self-registrationprocess. For example, the user may be asked to provide biometricinformation or identifiers (e.g., metrics related to humancharacteristics) via a mobile device to complement the identityinformation. In addition, or alternatively, other information tocomplete the self-registration process can include, for example, callinga user's landline phone with an interactive voice recognition system,messaging the user on a third-party platform (e.g., Google® Hangouts),or a custom company-provided mechanism like notifying a manager viaemail to click a link.

As part of self-registration setup, an administrator can either: selecta default self-registration verification process, select an existingself-registration verification process from various options, create andcustomize a new self-registration verification process (e.g., via thehandler class that actually determines how the user is created), orselect an existing self-registration verification process and modify it.The corresponding self-registration verification process allows toadministrator to specify or define how a user will be verified duringthe self-registration process after entering a credential at a promptpresented at the self-registration page. In one embodiment, theadministrator can specify their own custom self-registrationverification process (at 350) by specifying how a user is created duringthe self-registration process. In one embodiment, the admin can selectfrom various options for the type of user credential and an associatedself-registration verification process that can include, for example,any known types of identity verification challenge. Non-limitingexamples of corresponding self-registration verification process thatcan be selected by the administrator can include a prompt for aone-time-password or passcode sent via text message or via emailmessage, a redirection to an identity provider for verification duringself-registration (e.g., Facebook or Security Assertion Markup Language(SAML) identity provider for exchanging authentication and authorizationdata between the identity provider and a service provider), etc. When nocustomization is desired, the administrator can select (at 350) adefault user credential and a default self-registration verificationprocess corresponding to that default user credential.

At 460, the administrator for the particular service provider canfurther declaratively customize the user self-registration process andthe user interface elements that are used to define the userself-registration page for the particular service provider (e.g., for aparticular organization or for a particular tenant of a particularorganization). For example, the administrator for the particular serviceprovider can specify user creation information required as part of theuser self-registration process. The administrator can specify eithercustom or default options for user creation information. Theadministrator can select various options (e.g., using the dropdown menu310 of FIG. 3), such as, a default username for the user, the type ofuser and its association to other entries in the database such as acontact entry used for marketing purposes, access privileges of theuser, etc. In addition, the administrator can customize or extend theuser creation information using, for example, a scripting language. Whenno customization is desired with respect to the user creationinformation, the administrator can select (at 350) default user creationinformation (to the extent it is specified).

The method 400 then ends at 470 when the administrator deploys the userself-registration page for the particular service provider havingfeatures for implementing a user self-registration process that has beendefined or customized for the particular service provider. Theflexibility of this approach can allow each service provider to easilybuild and deploy their own customized user self-registration solutionwithout the need for customizing setup and coding efforts to do so. Aconfigurable user self-registration capability can be provided withinthe application platform that is easily customizable by each serviceprovider (e.g., organization and/or tenant) by selecting appropriateoptions within an easy to use GUI.

Automated Setup of Interview-Based Log In Process and Page

FIG. 5 illustrates a graphical user interface that is displayed at auser system of the administrator of a particular service provider forconfiguring or setting up an interview-based log in process and page forthat particular service provider in accordance with the disclosedembodiments. FIG. 6 illustrates a method 600 for configuring or settingup an interview-based log in process for a particular service providerin accordance with the disclosed embodiments. FIG. 6 will be describedwith reference to certain user interface element shown in FIG. 5.

As a preliminary matter, it should be understood that the user interfaceof FIG. 5 and the steps of the method 600 are not necessarily limiting.With reference to method 600, steps can be added, omitted, and/orperformed simultaneously without departing from the scope of theappended claims. It should be appreciated that the method 600 mayinclude any number of additional or alternative tasks, that the tasksshown in FIG. 6 need not be performed in the illustrated order, and thatthe method 600 may be incorporated into a more comprehensive procedureor process having additional functionality not described in detailherein. Moreover, one or more of the tasks shown in FIG. 6 couldpotentially be omitted from an embodiment of the method 600 as long asthe intended overall functionality remains intact. It should also beunderstood that the illustrated method 600 can be stopped at any time.The method 600 is computer-implemented in that various tasks or stepsthat are performed in connection with the method 600 may be performed bysoftware, hardware, firmware, or any combination thereof. Forillustrative purposes, the following description of the method 600 mayrefer to elements mentioned above in connection with FIGS. 1 and 2. Incertain embodiments, some or all steps of this process, and/orsubstantially equivalent steps, are performed by execution ofprocessor-readable instructions stored or included on aprocessor-readable medium. For instance, in the description of FIG. 6that follows, the user systems 212, and the application platform 210will be described as performing various acts, tasks or steps, but itshould be appreciated that this refers to processing system(s) of theseentities executing instructions to perform those various acts, tasks orsteps. Depending on the implementation, some of the processing system(s)can be centrally located, or distributed among a number of serversystems that work together. Furthermore, in the description of FIG. 6, aparticular example is described in which a user of a user systemperforms certain actions by interacting with other elements of thesystem via the user system. Various acts, tasks or steps FIG. 6 will bedescribed below with reference to screenshots shown in FIG. 5.

As shown in FIG. 6, the method 600 begins at 610, where an administratorfor a particular service provider selects an interview-based log inoption to configure the interview-based log in process and correspondingweb page. The interview-based log in page can be, for example, aninterview-based log in page for a web site or application offered bythat particular service provider. In one embodiment, the interview-basedlog in page can be, for example, an interview-based log in page for aweb site or application that is served or provided by the applicationplatform for a particular organization or for a particular tenant of aparticular organization of a cloud-based multi-tenant system.

In one embodiment, shown in FIG. 5, the administrator for a particularservice provider can utilize a drop-down menu 502 to select aninterview-based log in option that allows the administrator to configurean interview-based log in page for deployment. In one non-limitingembodiment, the interview-based log in page can employ a passwordlesslog in solution.

At 620 of FIG. 6, the administrator for the particular service providercan optionally customize graphical user interface elements and featuresthat are to be displayed as part of the log in page. As shown in FIG. 5,in one embodiment, the administrator may, if they choose, specify thingssuch as a background color (via text field 504), logo images (via textfield 506), or other graphical user interface elements (via other textfields that are not illustrated) that are to be displayed as part of thelog in page etc.

At 630, the administrator for the particular service provider candeclaratively customize the interview-based log in process and the userinterface elements that are used to define the interview-based log inprocess for the particular service provider (e.g., for a particularorganization or for a particular tenant of a particular organization).In one non-limiting embodiment, the log in process, is “interview-based”meaning that a user accessing the log in page is asked to fill inincreasing amounts of information as they proceed through the log in login process, and the information requested may vary depending oninformation previously provided.

For example, the administrator for the particular service provider cancustomize the type of log in prompt that allows the administrator todefine how users can be identified or “looked up” during log in. Forinstance, the administrator can select options such as email address,telephone number, social security number, or any other unique identifierfor the user, as the type of log in prompt to be used by to identify orlook-up the user. By specifying the type of log in prompt, theadministrator can define how users of an application or service offeredby for the particular service provider can be identified or “looked up”during log in (e.g., via Social Security number or last name). Inaddition, at 630, the administrator for the particular service providercan also customize the type of authentication mechanism to define how auser will be authenticated during the log in process after enteringtheir identity information at the log in prompt. In one non-limitingembodiment, the authentication mechanism can include a prompt for apassword, personal identification number or passcode, or any type ofidentity verification challenge, etc. The identity verificationchallenge can optionally be a 1-factor (1F) verification challenge, a2-factor (2F) verification challenge, etc. depending on theimplementation specified by the administrator. For instance, theadministrator can select options such as prompt for a password, a promptfor a one-time-password or passcode sent via text message or via emailmessage, a redirection to an identity provider (e.g., Facebook orSecurity Assertion Markup Language (SAML) identity provider forexchanging authentication and authorization data between the identityprovider and a service provider), etc.

In one embodiment, as shown in FIG. 5, to customize the type of userlook up and/or the type of authentication mechanism (e.g., type ofidentity verification challenge), the administrator for the particularservice provider can select a customization option via dropdown menu 510to specify a custom user look up and/or a custom authenticationmechanism. In other words, the admin for the particular service providercan change not only how the users are identified or looked up, but alsohow the user is to be verified during log in. This capability isoptional, but when desired, requires very little code to implement.However, in the event customization is not desired (at 630), theadministrator for the particular service provider can select, viadropdown menu 510 (of FIG. 5), a default code-based handler class. Thedefault code-based handler class defines default settings for (1) thetype of log in prompt (i.e., user look-up logic or mechanism thatspecifies how the user is looked up), and (2) the default settings fortype of authentication mechanism (e.g., type of identity verificationchallenge) to specify how the user is to be verified.

The method 600 then ends at 640 when the administrator deploys aninterview-based log in page (not illustrated) for the particular serviceprovider having features for implementing an interview-based log inprocess that has been defined for the particular service provider by theadministrator. The flexibility of this approach can allow each serviceprovider to easily build and deploy their own customized log in solutionwithout the need for customizing setup and coding efforts to do so. Aconfigurable log in capability can be provided within the applicationplatform that is easily customizable by each service provider (e.g.,organization and/or tenant) by selecting appropriate options within aneasy to use GUI.

An example of this is illustrated in Table 1 of FIG. 7. Eachorganization/tenant can have multiple self-registration/log in setupsfor separate use cases (e.g., different service providers) (e.g.,Salesforce communities). In accordance with the disclosed embodiments, agiven organization/tenant can support multiple service providers, andeach service provider can have different log in setups and/orself-registration setups that can be configured by an administrator. Forexample, an administrator for organization A can deploy aninterview-based log in page/process for service provider 1 that duringlog in requires a user to enter: their email address (as look-upinformation that identifies the user) and a prompt for aone-time-passcode that is delivered to the user via text/SMS (as anauthentication mechanism used to authenticate the user). On the otherhand, the administrator for organization A can deploy a differentinterview-based log in page/process for service provider 2 that duringlog in requires a user to enter: the last four digits of their socialsecurity number (as look-up information that identifies the user), and aprompt for a password (as an authentication mechanism used toauthenticate the user).

On the other hand, an administrator for an organization B can deploy aninterview-based log in page/process that during log in requires users:to enter a phone number (as look-up information that identifies theuser), and a prompt for a one-time-passcode that is delivered to theuser via email (as an authentication mechanism used to authenticate theuser). As another example, an administrator for an organization C candeploy an interview-based log in page/process that during log inrequires users: to enter an email address (as look-up information thatidentifies the user), and that uses a redirection to another identityprovider, such as Facebook, as the identity verification challenge (thatverifies identity of the user). As another example, an administrator foran organization D can deploy an interview-based log in page/process thatduring log in requires users: to enter an email address (as look-upinformation that identifies the user), and a prompt for aone-time-passcode that is delivered to the user via email (as anauthentication mechanism used to authenticate the user). As anotherexample, an administrator for an organization E can deploy aninterview-based log in page/process that during log in requires users:to enter some other identifier or identifying information that uniquelyidentifies the user, such as a self-selected vanity url, as look-upinformation, as look-up information (that identifies the user), and thatuses a redirection to another SAML identity provider as theauthentication mechanism used to authenticate the user. These sixexamples are non-limiting, and in general, any combination of look-upinformation that can be used to identify a user, and authenticationmechanism that can be used to verify identity of an identified user canbe configured by the administrator. For instance, the authenticationmechanism used to authenticate the user could be completed with ahardware token (e.g., U2F Security Key), any token-based identification,any knowledge-based identification (e.g., a password or personalidentification number) or any form of biometric authentication (e.g.,asking for a biometric on a mobile device such as fingerprint, palmveins, face recognition, DNA, palm print, hand geometry, irisrecognition, retina, voice samples, etc., and performing a one-to-onecomparison of a captured biometric with a specific template stored in abiometric database in order to verify the individual is the person theyclaim to be). Other authentication mechanisms can include calling auser's landline phone with an interactive voice recognition system,messaging the user on a third-party platform like Google® Hangouts, or acustom company-provided mechanism like notifying a manager via email toclick a link. The examples above are non-limiting.

The following description is of one example of a system in which thefeatures described above may be implemented. The components of thesystem described below are merely one example and should not beconstrued as limiting. The features described above with respect toFIGS. 1-7 may be implemented in any other type of computing environment,such as one with multiple servers, one with a single server, amulti-tenant server environment, a single-tenant server environment, orsome combination of the above.

FIG. 8 shows a block diagram of an example of an environment 810 inwhich an on-demand database service can be used in accordance with someimplementations. The environment 810 includes user systems 812, anetwork 814, a database system 816 (also referred to herein as a“cloud-based system”), a processor system 817, an application platform818, a network interface 820, tenant database 822 for storing tenantdata 823, system database 824 for storing system data 825, program code826 for implementing various functions of the system 816, and processspace 828 for executing database system processes and tenant-specificprocesses, such as running applications as part of an applicationhosting service. In some other implementations, environment 810 may nothave all of these components or systems, or may have other components orsystems instead of, or in addition to, those listed above.

In some implementations, the environment 810 is an environment in whichan on-demand database service exists. An on-demand database service,such as that which can be implemented using the system 816, is a servicethat is made available to users outside of the enterprise(s) that own,maintain or provide access to the system 816. As described above, suchusers generally do not need to be concerned with building or maintainingthe system 816. Instead, resources provided by the system 816 may beavailable for such users' use when the users need services provided bythe system 816; that is, on the demand of the users. Some on-demanddatabase services can store information from one or more tenants intotables of a common database image to form a multi-tenant database system(MTS). The term “multi-tenant database system” can refer to thosesystems in which various elements of hardware and software of a databasesystem may be shared by one or more customers or tenants. For example, agiven application server may simultaneously process requests for a greatnumber of customers, and a given database table may store rows of datasuch as feed items for a potentially much greater number of customers. Adatabase image can include one or more database objects. A relationaldatabase management system (RDBMS) or the equivalent can execute storageand retrieval of information against the database object(s).

Application platform 818 can be a framework that allows the applicationsof system 816 to execute, such as the hardware or softwareinfrastructure of the system 816. In some implementations, theapplication platform 818 enables the creation, management and executionof one or more applications developed by the provider of the on-demanddatabase service, users accessing the on-demand database service viauser systems 812, or third-party application developers accessing theon-demand database service via user systems 812.

In some implementations, the system 816 implements a web-based customerrelationship management (CRM) system. For example, in some suchimplementations, the system 816 includes application servers configuredto implement and execute CRM software applications as well as providerelated data, code, forms, renderable web pages and documents and otherinformation to and from user systems 812 and to store to, and retrievefrom, a database system related data, objects, and Web page content. Insome MTS implementations, data for multiple tenants may be stored in thesame physical database object in tenant database 822. In some suchimplementations, tenant data is arranged in the storage medium(s) oftenant database 822 so that data of one tenant is kept logicallyseparate from that of other tenants so that one tenant does not haveaccess to another tenant's data, unless such data is expressly shared.The system 816 also implements applications other than, or in additionto, a CRM application. For example, the system 816 can provide tenantaccess to multiple hosted (standard and custom) applications, includinga CRM application. User (or third party developer) applications, whichmay or may not include CRM, may be supported by the application platform818. The application platform 818 manages the creation and storage ofthe applications into one or more database objects and the execution ofthe applications in one or more virtual machines in the process space ofthe system 816.

According to some implementations, each system 816 is configured toprovide web pages, forms, applications, data and media content to user(client) systems 812 to support the access by user systems 812 astenants of system 816. As such, system 816 provides security mechanismsto keep each tenant's data separate unless the data is shared. If morethan one MTS is used, they may be located in close proximity to oneanother (for example, in a server farm located in a single building orcampus), or they may be distributed at locations remote from one another(for example, one or more servers located in city A and one or moreservers located in city B). As used herein, each MTS could include oneor more logically or physically connected servers distributed locally oracross one or more geographic locations. Additionally, the term “server”is meant to refer to a computing device or system, including processinghardware and process space(s), an associated storage medium such as amemory device or database, and, in some instances, a databaseapplication (for example, OODBMS or RDBMS) as is well known in the art.It should also be understood that “server system” and “server” are oftenused interchangeably herein. Similarly, the database objects describedherein can be implemented as part of a single database, a distributeddatabase, a collection of distributed databases, a database withredundant online or offline backups or other redundancies, etc., and caninclude a distributed database or storage network and associatedprocessing intelligence.

The network 814 can be or include any network or combination of networksof systems or devices that communicate with one another. For example,the network 814 can be or include any one or any combination of a LAN(local area network), WAN (wide area network), telephone network,wireless network, cellular network, point-to-point network, starnetwork, token ring network, hub network, or other appropriateconfiguration. The network 814 can include a TCP/IP (Transfer ControlProtocol and Internet Protocol) network, such as the global internetworkof networks often referred to as the “Internet” (with a capital “I”).The Internet will be used in many of the examples herein. However, itshould be understood that the networks that the disclosedimplementations can use are not so limited, although TCP/IP is afrequently implemented protocol.

The user systems 812 can communicate with system 816 using TCP/IP and,at a higher network level, other common Internet protocols tocommunicate, such as HTTP, FTP, AFS, WAP, etc. In an example where HTTPis used, each user system 812 can include an HTTP client commonlyreferred to as a “web browser” or simply a “browser” for sending andreceiving HTTP signals to and from an HTTP server of the system 816.Such an HTTP server can be implemented as the sole network interface 820between the system 816 and the network 814, but other techniques can beused in addition to or instead of these techniques. In someimplementations, the network interface 820 between the system 816 andthe network 814 includes load sharing functionality, such as round-robinHTTP request distributors to balance loads and distribute incoming HTTPrequests evenly over a number of servers. In MTS implementations, eachof the servers can have access to the MTS data; however, otheralternative configurations may be used instead.

The user systems 812 can be implemented as any computing device(s) orother data processing apparatus or systems usable by users to access thedatabase system 816. For example, any of user systems 812 can be adesktop computer, a work station, a laptop computer, a tablet computer,a handheld computing device, a mobile cellular phone (for example, a“smartphone”), or any other Wi-Fi-enabled device, wireless accessprotocol (WAP)-enabled device, or other computing device capable ofinterfacing directly or indirectly to the Internet or other network. Theterms “user system” and “computing device” are used interchangeablyherein with one another and with the term “computer.” As describedabove, each user system 812 typically executes an HTTP client, forexample, a web browsing (or simply “browsing”) program, such as a webbrowser based on the WebKit platform, Microsoft's Internet Explorerbrowser, Netscape's Navigator browser, Opera's browser, Mozilla'sFirefox browser, or a WAP-enabled browser in the case of a cellularphone, PDA or other wireless device, or the like, allowing a user (forexample, a subscriber of on-demand services provided by the system 816)of the user system 812 to access, process and view information, pagesand applications available to it from the system 816 over the network814.

Each user system 812 also typically includes one or more user inputdevices, such as a keyboard, a mouse, a trackball, a touch pad, a touchscreen, a pen or stylus or the like, for interacting with a graphicaluser interface (GUI) provided by the browser on a display (for example,a monitor screen, liquid crystal display (LCD), light-emitting diode(LED) display, among other possibilities) of the user system 812 inconjunction with pages, forms, applications and other informationprovided by the system 816 or other systems or servers. For example, theuser interface device can be used to access data and applications hostedby system 816, and to perform searches on stored data, and otherwiseallow a user to interact with various GUI pages that may be presented toa user. As discussed above, implementations are suitable for use withthe Internet, although other networks can be used instead of or inaddition to the Internet, such as an intranet, an extranet, a virtualprivate network (VPN), a non-TCP/IP based network, any LAN or WAN or thelike.

The users of user systems 812 may differ in their respective capacities,and the capacity of a particular user system 812 can be entirelydetermined by permissions (permission levels) for the current user ofsuch user system. For example, where a salesperson is using a particularuser system 812 to interact with the system 816, that user system canhave the capacities allotted to the salesperson. However, while anadministrator is using that user system 812 to interact with the system816, that user system can have the capacities allotted to thatadministrator. Where a hierarchical role model is used, users at onepermission level can have access to applications, data, and databaseinformation accessible by a lower permission level user, but may nothave access to certain applications, database information, and dataaccessible by a user at a higher permission level. Thus, different usersgenerally will have different capabilities with regard to accessing andmodifying application and database information, depending on the users'respective security or permission levels (also referred to as“authorizations”).

According to some implementations, each user system 812 and some or allof its components are operator-configurable using applications, such asa browser, including computer code executed using a central processingunit (CPU) such as an Intel Pentium® processor or the like. Similarly,the system 816 (and additional instances of an MTS, where more than oneis present) and all of its components can be operator-configurable usingapplication(s) including computer code to run using the processor system817, which may be implemented to include a CPU, which may include anIntel Pentium® processor or the like, or multiple CPUs.

The system 816 includes tangible computer-readable media havingnon-transitory instructions stored thereon/in that are executable by orused to program a server or other computing system (or collection ofsuch servers or computing systems) to perform some of the implementationof processes described herein. For example, computer program code 826can implement instructions for operating and configuring the system 816to intercommunicate and to process web pages, applications and otherdata and media content as described herein. In some implementations, thecomputer code 826 can be downloadable and stored on a hard disk, but theentire program code, or portions thereof, also can be stored in anyother volatile or non-volatile memory medium or device as is well known,such as a ROM or RAM, or provided on any media capable of storingprogram code, such as any type of rotating media including floppy disks,optical discs, digital versatile disks (DVD), compact disks (CD),microdrives, and magneto-optical disks, and magnetic or optical cards,nanosystems (including molecular memory ICs), or any other type ofcomputer-readable medium or device suitable for storing instructions ordata. Additionally, the entire program code, or portions thereof, may betransmitted and downloaded from a software source over a transmissionmedium, for example, over the Internet, or from another server, as iswell known, or transmitted over any other existing network connection asis well known (for example, extranet, VPN, LAN, etc.) using anycommunication medium and protocols (for example, TCP/IP, HTTP, HTTPS,Ethernet, etc.) as are well known. It will also be appreciated thatcomputer code for the disclosed implementations can be realized in anyprogramming language that can be executed on a server or other computingsystem such as, for example, C, C++, HTML, any other markup language,Java™, JavaScript, ActiveX, any other scripting language, such asVBScript, and many other programming languages as are well known may beused. (Java™ is a trademark of Sun Microsystems, Inc.).

FIG. 9 shows a block diagram of example implementations of elements ofFIG. 8 and example interconnections between these elements according tosome implementations. That is, FIG. 9 also illustrates environment 810,but FIG. 9, various elements of the system 816 and variousinterconnections between such elements are shown with more specificityaccording to some more specific implementations. Elements from FIG. 8that are also shown in FIG. 9 will use the same reference numbers inFIG. 9 as were used in FIG. 8. Additionally, in FIG. 9, the user system812 includes a processor system 912A, a memory system 912B, an inputsystem 912C, and an output system 912D. The processor system 912A caninclude any suitable combination of one or more processors. The memorysystem 912B can include any suitable combination of one or more memorydevices. The input system 912C can include any suitable combination ofinput devices, such as one or more touchscreen interfaces, keyboards,mice, trackballs, scanners, cameras, or interfaces to networks. Theoutput system 912D can include any suitable combination of outputdevices, such as one or more display devices, printers, or interfaces tonetworks.

In FIG. 9, the network interface 820 of FIG. 8 is implemented as a setof HTTP application servers 900 ₁-1400 _(N). Each application server900, also referred to herein as an “app server,” is configured tocommunicate with tenant database 822 and the tenant data 923 therein, aswell as system database 824 and the system data 925 therein, to serverequests received from the user systems 912. The tenant data 923 can bedivided into individual tenant storage spaces 913, which can bephysically or logically arranged or divided. Within each tenant storagespace 913, tenant data 914 and application metadata 916 can similarly beallocated for each user. For example, a copy of a user's most recentlyused (MRU) items can be stored to user storage 914. Similarly, a copy ofMRU items for an entire organization that is a tenant can be stored totenant storage space 913.

The process space 828 includes system process space 902, individualtenant process spaces 904 and a tenant management process space 910. Theapplication platform 818 includes an application setup mechanism 938that supports application developers' creation and management ofapplications. Such applications and others can be saved as metadata intotenant database 822 by save routines 936 for execution by subscribers asone or more tenant process spaces 904 managed by tenant managementprocess 910, for example. Invocations to such applications can be codedusing PL/SOQL 934, which provides a programming language style interfaceextension to API 932. A detailed description of some PL/SOQL languageimplementations is discussed in commonly assigned U.S. Pat. No.7,730,478, titled METHOD AND SYSTEM FOR ALLOWING ACCESS TO DEVELOPEDAPPLICATIONS VIA A MULTI-TENANT ON-DEMAND DATABASE SERVICE, by CraigWeissman, issued on Jun. 1, 2010, and hereby incorporated by referencein its entirety and for all purposes. Invocations to applications can bedetected by one or more system processes, which manage retrievingapplication metadata 816 for the subscriber making the invocation andexecuting the metadata as an application in a virtual machine.

The system 816 of FIG. 9 also includes a user interface (UI) 930 and anapplication programming interface (API) 932 to system 816 residentprocesses to users or developers at user systems 912. In some otherimplementations, the environment 810 may not have the same elements asthose listed above or may have other elements instead of, or in additionto, those listed above.

Each application server 900 can be communicably coupled with tenantdatabase 822 and system database 824, for example, having access totenant data 923 and system data 925, respectively, via a differentnetwork connection. For example, one application server 900 ₁ can becoupled via the network 814 (for example, the Internet), anotherapplication server 900 _(N) can be coupled via a direct network link,and another application server (not illustrated) can be coupled by yet adifferent network connection. Transfer Control Protocol and InternetProtocol (TCP/IP) are examples of typical protocols that can be used forcommunicating between application servers 900 and the system 816.However, it will be apparent to one skilled in the art that othertransport protocols can be used to optimize the system 816 depending onthe network interconnections used.

In some implementations, each application server 900 is configured tohandle requests for any user associated with any organization that is atenant of the system 816. Because it can be desirable to be able to addand remove application servers 900 from the server pool at any time andfor various reasons, in some implementations there is no server affinityfor a user or organization to a specific application server 900. In somesuch implementations, an interface system implementing a load balancingfunction (for example, an F5 Big-IP load balancer) is communicablycoupled between the application servers 900 and the user systems 912 todistribute requests to the application servers 900. In oneimplementation, the load balancer uses a least-connections algorithm toroute user requests to the application servers 900. Other examples ofload balancing algorithms, such as round robin andobserved-response-time, also can be used. For example, in someinstances, three consecutive requests from the same user could hit threedifferent application servers 900, and three requests from differentusers could hit the same application server 900. In this manner, by wayof example, system 816 can be a multi-tenant system in which system 816handles storage of, and access to, different objects, data andapplications across disparate users and organizations.

In one example storage use case, one tenant can be a company thatemploys a sales force where each salesperson uses system 816 to manageaspects of their sales. A user can maintain contact data, leads data,customer follow-up data, performance data, goals and progress data,etc., all applicable to that user's personal sales process (for example,in tenant database 822). In an example of a MTS arrangement, because allof the data and the applications to access, view, modify, report,transmit, calculate, etc., can be maintained and accessed by a usersystem 912 having little more than network access, the user can managehis or her sales efforts and cycles from any of many different usersystems. For example, when a salesperson is visiting a customer and thecustomer has Internet access in their lobby, the salesperson can obtaincritical updates regarding that customer while waiting for the customerto arrive in the lobby.

While each user's data can be stored separately from other users' dataregardless of the employers of each user, some data can beorganization-wide data shared or accessible by several users or all ofthe users for a given organization that is a tenant. Thus, there can besome data structures managed by system 816 that are allocated at thetenant level while other data structures can be managed at the userlevel. Because an MTS can support multiple tenants including possiblecompetitors, the MTS can have security protocols that keep data,applications, and application use separate. Also, because many tenantsmay opt for access to an MTS rather than maintain their own system,redundancy, up-time, and backup are additional functions that can beimplemented in the MTS. In addition to user-specific data andtenant-specific data, the system 816 also can maintain system level datausable by multiple tenants or other data. Such system level data caninclude industry reports, news, postings, and the like that are sharableamong tenants.

In some implementations, the user systems 912 (which also can be clientsystems) communicate with the application servers 900 to request andupdate system-level and tenant-level data from the system 816. Suchrequests and updates can involve sending one or more queries to tenantdatabase 822 or system database 824. The system 816 (for example, anapplication server 900 in the system 816) can automatically generate oneor more SQL statements (for example, one or more SQL queries) designedto access the desired information. System database 824 can generatequery plans to access the requested data from the database. The term“query plan” generally refers to one or more operations used to accessinformation in a database system.

Each database can generally be viewed as a collection of objects, suchas a set of logical tables, containing data fitted into predefined orcustomizable categories. A “table” is one representation of a dataobject, and may be used herein to simplify the conceptual description ofobjects and custom objects according to some implementations. It shouldbe understood that “table” and “object” may be used interchangeablyherein. Each table generally contains one or more data categorieslogically arranged as columns or fields in a viewable schema. Each rowor element of a table can contain an instance of data for each categorydefined by the fields. For example, a CRM database can include a tablethat describes a customer with fields for basic contact information suchas name, address, phone number, fax number, etc. Another table candescribe a purchase order, including fields for information such ascustomer, product, sale price, date, etc. In some MTS implementations,standard entity tables can be provided for use by all tenants. For CRMdatabase applications, such standard entities can include tables forcase, account, contact, lead, and opportunity data objects, eachcontaining pre-defined fields. As used herein, the term “entity” alsomay be used interchangeably with “object” and “table.”

In some MTS implementations, tenants are allowed to create and storecustom objects, or may be allowed to customize standard entities orobjects, for example by creating custom fields for standard objects,including custom index fields. Commonly assigned U.S. Pat. No.7,779,039, titled CUSTOM ENTITIES AND FIELDS IN A MULTI-TENANT DATABASESYSTEM, by Weissman et al., issued on Aug. 17, 2010, and herebyincorporated by reference in its entirety and for all purposes, teachessystems and methods for creating custom objects as well as customizingstandard objects in a multi-tenant database system. In someimplementations, for example, all custom entity data rows are stored ina single multi-tenant physical table, which may contain multiple logicaltables per organization. It is transparent to customers that theirmultiple “tables” are in fact stored in one large table or that theirdata may be stored in the same table as the data of other customers.

FIG. 10A shows a system diagram illustrating example architecturalcomponents of an on-demand database service environment 1000 accordingto some implementations. A client machine communicably connected withthe cloud 1004, generally referring to one or more networks incombination, as described herein, can communicate with the on-demanddatabase service environment 1000 via one or more edge routers 1008 and1012. A client machine can be any of the examples of user systems 12described above. The edge routers can communicate with one or more coreswitches 1020 and 1024 through a firewall 1016. The core switches cancommunicate with a load balancer 1028, which can distribute server loadover different pods, such as the pods 1040 and 1044. The pods 1040 and1044, which can each include one or more servers or other computingresources, can perform data processing and other operations used toprovide on-demand services. Communication with the pods can be conductedvia pod switches 1032 and 1036. Components of the on-demand databaseservice environment can communicate with database storage 1056 through adatabase firewall 1048 and a database switch 1052.

As shown in FIGS. 10A and 10B, accessing an on-demand database serviceenvironment can involve communications transmitted among a variety ofdifferent hardware or software components. Further, the on-demanddatabase service environment 1000 is a simplified representation of anactual on-demand database service environment. For example, while onlyone or two devices of each type are shown in FIGS. 10A and 10B, someimplementations of an on-demand database service environment can includeanywhere from one to several devices of each type. Also, the on-demanddatabase service environment need not include each device shown in FIGS.10A and 10B, or can include additional devices not shown in FIGS. 10Aand 10B.

Additionally, it should be appreciated that one or more of the devicesin the on-demand database service environment 1000 can be implemented onthe same physical device or on different hardware. Some devices can beimplemented using hardware or a combination of hardware and software.Thus, terms such as “data processing apparatus,” “machine,” “server” and“device” as used herein are not limited to a single hardware device,rather references to these terms can include any suitable combination ofhardware and software configured to provide the described functionality.

The cloud 1004 is intended to refer to a data network or multiple datanetworks, often including the Internet. Client machines communicablyconnected with the cloud 1004 can communicate with other components ofthe on-demand database service environment 1000 to access servicesprovided by the on-demand database service environment. For example,client machines can access the on-demand database service environment toretrieve, store, edit, or process information. In some implementations,the edge routers 1008 and 1012 route packets between the cloud 1004 andother components of the on-demand database service environment 1000. Forexample, the edge routers 1008 and 1012 can employ the Border GatewayProtocol (BGP). The BGP is the core routing protocol of the Internet.The edge routers 1008 and 1012 can maintain a table of IP networks or‘prefixes’, which designate network reachability among autonomoussystems on the Internet.

In some implementations, the firewall 1016 can protect the innercomponents of the on-demand database service environment 1000 fromInternet traffic. The firewall 1016 can block, permit, or deny access tothe inner components of the on-demand database service environment 1000based upon a set of rules and other criteria. The firewall 1016 can actas one or more of a packet filter, an application gateway, a statefulfilter, a proxy server, or any other type of firewall.

In some implementations, the core switches 1020 and 1024 arehigh-capacity switches that transfer packets within the on-demanddatabase service environment 1000. The core switches 1020 and 1024 canbe configured as network bridges that quickly route data betweendifferent components within the on-demand database service environment.In some implementations, the use of two or more core switches 1020 and1024 can provide redundancy or reduced latency.

In some implementations, the pods 1040 and 1044 perform the core dataprocessing and service functions provided by the on-demand databaseservice environment. Each pod can include various types of hardware orsoftware computing resources. An example of the pod architecture isdiscussed in greater detail with reference to FIG. 10B. In someimplementations, communication between the pods 1040 and 1044 isconducted via the pod switches 1032 and 1036. The pod switches 1032 and1036 can facilitate communication between the pods 1040 and 1044 andclient machines communicably connected with the cloud 1004, for examplevia core switches 1020 and 1024. Also, the pod switches 1032 and 1036may facilitate communication between the pods 1040 and 1044 and thedatabase storage 1056. In some implementations, the load balancer 1028can distribute workload between the pods 1040 and 1044. Balancing theon-demand service requests between the pods can assist in improving theuse of resources, increasing throughput, reducing response times, orreducing overhead. The load balancer 1028 may include multilayerswitches to analyze and forward traffic.

In some implementations, access to the database storage 1056 is guardedby a database firewall 1048. The database firewall 1048 can act as acomputer application firewall operating at the database applicationlayer of a protocol stack. The database firewall 1048 can protect thedatabase storage 1056 from application attacks such as structure querylanguage (SQL) injection, database rootkits, and unauthorizedinformation disclosure. In some implementations, the database firewall1048 includes a host using one or more forms of reverse proxy servicesto proxy traffic before passing it to a gateway router. The databasefirewall 1048 can inspect the contents of database traffic and blockcertain content or database requests. The database firewall 1048 canwork on the SQL application level atop the TCP/IP stack, managingapplications' connection to the database or SQL management interfaces aswell as intercepting and enforcing packets traveling to or from adatabase network or application interface.

In some implementations, communication with the database storage 1056 isconducted via the database switch 1052. The multi-tenant databasestorage 1056 can include more than one hardware or software componentsfor handling database queries. Accordingly, the database switch 1052 candirect database queries transmitted by other components of the on-demanddatabase service environment (for example, the pods 1040 and 1044) tothe correct components within the database storage 1056. In someimplementations, the database storage 1056 is an on-demand databasesystem shared by many different organizations as described above withreference to FIG. 8 and FIG. 9.

FIG. 10B shows a system diagram further illustrating examplearchitectural components of an on-demand database service environmentaccording to some implementations. The pod 1044 can be used to renderservices to a user of the on-demand database service environment 1000.In some implementations, each pod includes a variety of servers or othersystems. The pod 1044 includes one or more content batch servers 1064,content search servers 1068, query servers 1082, file force servers1086, access control system (ACS) servers 1080, batch servers 1084, andapp servers 1088. The pod 1044 also can include database instances 1090,quick file systems (QFS) 1092, and indexers 1094. In someimplementations, some or all communication between the servers in thepod 1044 can be transmitted via the switch 1036.

In some implementations, the app servers 1088 include a hardware orsoftware framework dedicated to the execution of procedures (forexample, programs, routines, scripts) for supporting the construction ofapplications provided by the on-demand database service environment 1000via the pod 1044. In some implementations, the hardware or softwareframework of an app server 1088 is configured to execute operations ofthe services described herein, including performance of the blocks ofvarious methods or processes described herein. In some alternativeimplementations, two or more app servers 1088 can be included andcooperate to perform such methods, or one or more other serversdescribed herein can be configured to perform the disclosed methods.

The content batch servers 1064 can handle requests internal to the pod.Some such requests can be long-running or not tied to a particularcustomer. For example, the content batch servers 1064 can handlerequests related to log mining, cleanup work, and maintenance tasks. Thecontent search servers 1068 can provide query and indexer functions. Forexample, the functions provided by the content search servers 1068 canallow users to search through content stored in the on-demand databaseservice environment. The file force servers 1086 can manage requests forinformation stored in the File force storage 1098. The File forcestorage 1098 can store information such as documents, images, and basiclarge objects (BLOBs). By managing requests for information using thefile force servers 1086, the image footprint on the database can bereduced. The query servers 1082 can be used to retrieve information fromone or more file storage systems. For example, the query system 1082 canreceive requests for information from the app servers 1088 and transmitinformation queries to the NFS 1096 located outside the pod.

The pod 1044 can share a database instance 1090 configured as amulti-tenant environment in which different organizations share accessto the same database. Additionally, services rendered by the pod 1044may call upon various hardware or software resources. In someimplementations, the ACS servers 1080 control access to data, hardwareresources, or software resources. In some implementations, the batchservers 1084 process batch jobs, which are used to run tasks atspecified times. For example, the batch servers 1084 can transmitinstructions to other servers, such as the app servers 1088, to triggerthe batch jobs.

In some implementations, the QFS 1092 is an open source file storagesystem available from Sun Microsystems® of Santa Clara, Calif. The QFScan serve as a rapid-access file storage system for storing andaccessing information available within the pod 1044. The QFS 1092 cansupport some volume management capabilities, allowing many disks to begrouped together into a file storage system. File storage systemmetadata can be kept on a separate set of disks, which can be useful forstreaming applications where long disk seeks cannot be tolerated. Thus,the QFS system can communicate with one or more content search servers1068 or indexers 1094 to identify, retrieve, move, or update data storedin the network file storage systems 1096 or other storage systems.

In some implementations, one or more query servers 1082 communicate withthe NFS 1096 to retrieve or update information stored outside of the pod1044. The NFS 1096 can allow servers located in the pod 1044 to accessinformation to access files over a network in a manner similar to howlocal storage is accessed. In some implementations, queries from thequery servers 1082 are transmitted to the NFS 1096 via the load balancer1028, which can distribute resource requests over various resourcesavailable in the on-demand database service environment. The NFS 1096also can communicate with the QFS 1092 to update the information storedon the NFS 1096 or to provide information to the QFS 1092 for use byservers located within the pod 1044.

In some implementations, the pod includes one or more database instances1090. The database instance 1090 can transmit information to the QFS1092. When information is transmitted to the QFS, it can be availablefor use by servers within the pod 1044 without using an additionaldatabase call. In some implementations, database information istransmitted to the indexer 1094. Indexer 1094 can provide an index ofinformation available in the database 1090 or QFS 1092. The indexinformation can be provided to file force servers 1086 or the QFS 1092.

FIG. 11 illustrates a diagrammatic representation of a machine in theexemplary form of a computer system 1100 within which a set ofinstructions, for causing the machine to perform any one or more of themethodologies discussed herein, may be executed. The system 1100 may bein the form of a computer system within which a set of instructions, forcausing the machine to perform any one or more of the methodologiesdiscussed herein, may be executed. In alternative embodiments, themachine may be connected (e.g., networked) to other machines in a LAN,an intranet, an extranet, or the Internet. The machine may operate inthe capacity of a server machine in client-server network environment.The machine may be a personal computer (PC), a set-top box (STB), aserver, a network router, switch or bridge, or any machine capable ofexecuting a set of instructions (sequential or otherwise) that specifyactions to be taken by that machine. Further, while only a singlemachine is illustrated, the term “machine” shall also be taken toinclude any collection of machines that individually or jointly executea set (or multiple sets) of instructions to perform any one or more ofthe methodologies discussed herein.

The exemplary computer system 1100 includes a processing device(processor) 1102, a main memory 1104 (e.g., read-only memory (ROM),flash memory, dynamic random access memory (DRAM) such as synchronousDRAM (SDRAM)), a static memory 1106 (e.g., flash memory, static randomaccess memory (SRAM)), and a data storage device 1118, which communicatewith each other via a bus 1130.

Processing device 1102 represents one or more general-purpose processingdevices such as a microprocessor, central processing unit, or the like.More particularly, the processing device 1102 may be a complexinstruction set computing (CISC) microprocessor, reduced instruction setcomputing (RISC) microprocessor, very long instruction word (VLIW)microprocessor, or a processor implementing other instruction sets orprocessors implementing a combination of instruction sets. Theprocessing device 1102 may also be one or more special-purposeprocessing devices such as an application specific integrated circuit(ASIC), a field programmable gate array (FPGA), a digital signalprocessor (DSP), network processor, or the like.

The computer system 1100 may further include a network interface device1108. The computer system 1100 also may include a video display unit1110 (e.g., a liquid crystal display (LCD) or a cathode ray tube (CRT)),an alphanumeric input device 1112 (e.g., a keyboard), a cursor controldevice 1114 (e.g., a mouse), and a signal generation device 1116 (e.g.,a speaker).

The data storage device 1118 may include a computer-readable medium 1128on which is stored one or more sets of instructions 1122 (e.g.,instructions of in-memory buffer service 114) embodying any one or moreof the methodologies or functions described herein. The instructions1122 may also reside, completely or at least partially, within the mainmemory 1104 and/or within processing logic 1126 of the processing device1102 during execution thereof by the computer system 1100, the mainmemory 1104 and the processing device 1102 also constitutingcomputer-readable media. The instructions may further be transmitted orreceived over a network 1120 via the network interface device 1108.

While the computer-readable storage medium 1128 is shown in an exemplaryembodiment to be a single medium, the term “computer-readable storagemedium” should be taken to include a single medium or multiple media(e.g., a centralized or distributed database, and/or associated cachesand servers) that store the one or more sets of instructions. The term“computer-readable storage medium” shall also be taken to include anymedium that is capable of storing, encoding or carrying a set ofinstructions for execution by the machine and that cause the machine toperform any one or more of the methodologies of the present invention.The term “computer-readable storage medium” shall accordingly be takento include, but not be limited to, solid-state memories, optical media,and magnetic media.

The preceding description sets forth numerous specific details such asexamples of specific systems, components, methods, and so forth, inorder to provide a good understanding of several embodiments of thepresent invention. It will be apparent to one skilled in the art,however, that at least some embodiments of the present invention may bepracticed without these specific details. In other instances, well-knowncomponents or methods are not described in detail or are presented insimple block diagram format in order to avoid unnecessarily obscuringthe present invention. Thus, the specific details set forth are merelyexemplary. Particular implementations may vary from these exemplarydetails and still be contemplated to be within the scope of the presentinvention.

In the above description, numerous details are set forth. It will beapparent, however, to one of ordinary skill in the art having thebenefit of this disclosure, that embodiments of the invention may bepracticed without these specific details. In some instances, well-knownstructures and devices are shown in block diagram form, rather than indetail, in order to avoid obscuring the description.

Some portions of the detailed description are presented in terms ofalgorithms and symbolic representations of operations on data bitswithin a computer memory. These algorithmic descriptions andrepresentations are the means used by those skilled in the dataprocessing arts to most effectively convey the substance of their workto others skilled in the art. An algorithm is here, and generally,conceived to be a self-consistent sequence of steps leading to a desiredresult. The steps are those requiring physical manipulations of physicalquantities. Usually, though not necessarily, these quantities take theform of electrical or magnetic signals capable of being stored,transferred, combined, compared, and otherwise manipulated. It hasproven convenient at times, principally for reasons of common usage, torefer to these signals as bits, values, elements, symbols, characters,terms, numbers, or the like.

It should be borne in mind, however, that all of these and similar termsare to be associated with the appropriate physical quantities and aremerely convenient labels applied to these quantities. Unlessspecifically stated otherwise as apparent from the above discussion, itis appreciated that throughout the description, discussions utilizingterms such as “determining”, “identifying”, “adding”, “selecting” or thelike, refer to the actions and processes of a computer system, orsimilar electronic computing device, that manipulates and transformsdata represented as physical (e.g., electronic) quantities within thecomputer system's registers and memories into other data similarlyrepresented as physical quantities within the computer system memoriesor registers or other such information storage, transmission or displaydevices.

Embodiments of the invention also relate to an apparatus for performingthe operations herein. This apparatus may be specially constructed forthe required purposes, or it may comprise a general purpose computerselectively activated or reconfigured by a computer program stored inthe computer. Such a computer program may be stored in a computerreadable storage medium, such as, but not limited to, any type of diskincluding floppy disks, optical disks, CD-ROMs, and magnetic-opticaldisks, read-only memories (ROMs), random access memories (RAMs), EPROMs,EEPROMs, magnetic or optical cards, or any type of media suitable forstoring electronic instructions.

The algorithms and displays presented herein are not inherently relatedto any particular computer or other apparatus. Various special-purposeand general-purpose systems may be used with programs in accordance withthe teachings herein, or it may prove convenient to construct a morespecialized apparatus to perform the required method steps. The requiredstructure for a variety of these systems will appear from thedescription below. In addition, the present invention is not describedwith reference to any particular programming language. It will beappreciated that a variety of programming languages may be used toimplement the teachings of the invention as described herein.

While at least one exemplary embodiment has been presented in theforegoing detailed description, it should be appreciated that a vastnumber of variations exist. It should also be appreciated that theexemplary embodiment or embodiments described herein are not intended tolimit the scope, applicability, or configuration of the claimed subjectmatter in any way. Rather, the foregoing detailed description willprovide those skilled in the art with a convenient road map forimplementing the described embodiment or embodiments. It should beunderstood that various changes can be made in the function andarrangement of elements without departing from the scope defined by theclaims, which includes known equivalents and foreseeable equivalents atthe time of filing this patent application.

What is claimed is:
 1. A method for configuring an interview-based login process and a corresponding interview-based log in page for aparticular service provider, the method comprising: displaying, at auser system of an administrator of the particular service provider, agraphical user interface that includes a plurality of options forconfiguring different interview-based log in processes and correspondinginterview-based log in pages for the particular service provider; viathe graphical user interface: selecting an interview-based log in optionthat allows the administrator to configure the interview-based log inprocess and the corresponding interview-based log in page for deploymentby that particular service provider; specifying a type of log in promptto define how a user is identified and looked-up during theinterview-based log in process for that service provider, wherein thetype of log in prompt is one of a plurality of different types of log inprompts that can be specified by the administrator; and specifying atype of authentication mechanism to define how the user will beauthenticated as part of the interview-based log in process for theservice provider after entering their identity information at thespecified log in prompt for the service provider, wherein the type ofauthentication mechanism is one of a plurality of different types ofauthentication mechanisms that can be specified by the administrator. 2.The method according to claim 1, further comprising: automaticallydeploying the interview-based log in page having features and logic forthe interview-based log in process that are customized for thatparticular service provider.
 3. The method according to claim 1, whereinthe interview-based log in page is for a web site, an application or aservice offered by that particular service provider via an applicationplatform of a cloud-based server system, wherein the particular serviceprovider is one of a plurality of service providers that offer resourcesto users via the application platform, and wherein administrators foreach service provider can declaratively configure via the graphical userinterface a customized interview-based log in page and a correspondingcustomized interview-based log in process and deploy the customizedinterview-based log in page and the corresponding customizedinterview-based log in process via the application platform.
 4. Themethod according to claim 1, the method further comprising: selecting auser self-registration setup option to configure a userself-registration process and a corresponding user self-registrationpage for deployment by that particular service provider, wherein thecorresponding user self-registration page is for a web site, anapplication or a service offered by that particular service providerthat is provided by an application platform of a cloud-basedmulti-tenant system; specifying a type of identifier associated with theuser to be verified as part of the user self-registration process forthe service provider, and a type of self-registration verificationprocess to define how a user will be verified as part of the userself-registration process for the service provider after providing thetype of identifier for the service provider.
 5. The method according toclaim 4, wherein the identifier is a user credential that defines howthe user will contacted to complete the user self-registration process,wherein the self-registration verification process is a correspondingself-registration verification process that specifies how the user willbe verified as part of the user self-registration process after enteringthe user credential at a prompt presented at the corresponding userself-registration page, and wherein the corresponding self-registrationverification process allows the user credential entered at the promptpresented at the corresponding user self-registration page to beverified.
 6. The method according to claim 4, further comprising: viathe graphical user interface: selecting which user fields are to beincluded in a graphical user interface of the correspondingself-registration page to collect user information during the userself-registration process, wherein the user fields comprise a first nameof the user, a last name of the user, a username of the user, an emailaddress of the user, a phone number of the user, and a nickname of theuser; selecting an option to specify whether the user is required to seta password as part of the user self-registration process; and specifyinguser creation information required as part of the user self-registrationprocess.
 7. The method according to claim 1, wherein the correspondinginterview-based log in page is for a web site, an application or aservice offered by that particular service provider that is provided byan application platform of a cloud-based multi-tenant server system. 8.The method according to claim 1, wherein the type of log in promptaccepts one or more of: an email address of the user, a telephone numberof the user, a social security number of the user, or another uniqueidentifier for the user, and wherein the type of authenticationmechanism includes one or more of: a prompt for a password, a prompt fora one-time-password or passcode sent to the user via text message or viaemail message, a redirection to an identity provider for authentication,and a prompt for a biometric input by the user.
 9. A system comprising:a user system of an administrator of the particular service provider,comprising: a display configured to display a graphical user interfacethat includes a plurality of options for configuring differentinterview-based log in processes and corresponding interview-based login pages for the particular service provider, wherein the graphical userinterface is configured to receive: a first input to select one of theoptions to configure the interview-based log in process and thecorresponding interview-based log in page for deployment by thatparticular service provider; a second input to specify a type of log inprompt associated with a user to be verified as part of theinterview-based log in process for the service provider, wherein thetype log in prompt defines how the user is identified and looked-upduring the interview-based log in process for the service provider, andwherein the type of log in prompt is one of a plurality of differenttypes of identifiers that can be specified by the administrator; and athird input to specify a type of authentication mechanism to define howthe user will be authenticated as part of the interview-based log inprocess for the service provider, wherein the type of authenticationmechanism defines how the user will be authenticated as part of theinterview-based log in process for that service provider, wherein thetype of authentication mechanism is one of a plurality of differenttypes of authentication mechanisms that can be specified by theadministrator; and a server system in communication with the usersystem, wherein server system comprises: an application platform isconfigured to receive the first input, the second input, and the thirdinput, and to generate the interview-based log in page based on thefirst input, the second input and the third input, wherein theinterview-based log in page comprises features and logic for theinterview-based log in process that are customized for that particularservice provider.
 10. The system according to claim 9, wherein theapplication platform is further configured to automatically deploy theinterview-based log in page in response to a request from the user, andwherein the interview-based log in page is for a web site, anapplication or a service offered by that particular service provider viathe application platform, wherein the server system is a cloud-basedserver system.
 11. The system according to claim 9, wherein theparticular service provider is one of a plurality of service providersthat offer resources to users via the application platform, and whereinadministrators for each service provider can declaratively configure,via the graphical user interface, a customized interview-based log inpage and a corresponding customized interview-based log in process forthat particular service provider, and automatically deploy thecustomized interview-based log in page and the corresponding customizedinterview-based log in process to users via the application platformupon configuration of the customized interview-based log in page and thecorresponding customized interview-based log in process.
 12. The systemaccording to claim 9, wherein the display is further configured todisplay: another graphical user interface that is configured to receive:a fourth input to select a user self-registration setup option toconfigure a user self-registration process and a corresponding userself-registration page for deployment by that particular serviceprovider; and a fifth input to select from a plurality of options: atype of user credential that defines how the user will contacted aftercompleting the user self-registration process, and a particular userself-registration process to define how the user will be verified forthat service provider.
 13. The system according to claim 9, wherein theparticular user self-registration process is a correspondingself-registration verification process that specifies how the user willbe verified as part of the user self-registration process after enteringthe user credential at a prompt presented at the corresponding userself-registration page, and wherein the corresponding self-registrationverification process allows the user credential entered at the promptpresented at the corresponding user self-registration page to beverified redirection.
 14. The system according to claim 9, wherein theother graphical user interface is further configured to receive otherinputs that specify: user fields that are to be included in a graphicaluser interface of the corresponding self-registration page to collectuser information during the user self-registration process, wherein theuser fields comprise one or more of a first name of the user, a lastname of the user, a username of the user, an email address of the user,a phone number of the user, and a nickname of the user; whether the useris required to set a password as part of the user self-registrationprocess; and user creation information required as part of the userself-registration process.
 15. The system according to claim 9, whereinthe corresponding interview-based log in page is for a web site, anapplication or a service offered by that particular service providerthat is provided by an application platform of a cloud-basedmulti-tenant system.
 16. The system according to claim 9, wherein thetype of log in prompt accepts one of: an email address of the user, atelephone number of the user, a social security number of the user, oranother unique identifier for the user, and wherein the type ofauthentication mechanism includes one or more of: a prompt for apassword, a prompt for a one-time-password or passcode sent to the uservia text message or via email message, a redirection to an identityprovider for authentication, and a prompt for a biometric input by theuser.
 17. A computing system, comprising: a processor; and a displayconfigured to display a graphical user interface, the graphical userinterface comprising: a first user interface element that presents aplurality of options for configuring different interview-based log inprocesses and corresponding interview-based log in pages for aparticular service provider, wherein the graphical user interface isconfigured to receive a first input to select one of the plurality ofoptions to configure an interview-based log in process and acorresponding interview-based log in page for automatic deployment bythe particular service provider; a second user interface elementconfigured to receive a second input to specify a type of log in promptassociated with a user to be authenticated as part of theinterview-based log in process for the service provider, wherein thetype of log in prompt is one of a plurality of different types of log inprompts that can be specified, wherein each type of log in promptdefines how the user is identified and looked-up during theinterview-based log in process for that service provider; and a thirduser interface element configured to receive a third input to specify atype of authentication mechanism to define how the user will beauthenticated as part of the interview-based log in process for theservice provider after entering information at the specified log inprompt, wherein the type of authentication mechanism is one of aplurality of different types of authentication mechanisms that can bespecified by the administrator, and wherein the processor is configuredto communicate the first input, the second input, and the third input toa server system that comprises an application platform, wherein theapplication platform is configured to generate the correspondinginterview-based log in page based on the first input, the second inputand the third input, wherein the corresponding interview-based log inpage comprises features and logic for the interview-based log in processthat are customized for that particular service provider.
 18. Thecomputing system according to claim 17, wherein the display is furtherconfigured to display another graphical user interface for a userself-registration process and a corresponding user self-registrationpage, wherein a fourth input selects a user self-registration setupoption to configure the user self-registration process and thecorresponding user self-registration page for deployment by thatparticular service provider, wherein a fifth input selects the type ofverification process that defines how the user will be verified as partof the user self-registration process for the service provider afterentering a user credential at the corresponding user self-registrationpage, and wherein the corresponding user self-registration page is for aweb site, an application or a service offered by that particular serviceprovider that is provided by the application platform of a cloud-basedmulti-tenant system.
 19. The computing system according to claim 18,wherein the identifier is a user credential that defines how the userwill contacted to complete the user self-registration process, whereinthe verification process is a corresponding self-registrationverification process that specifies how the user will be verified aspart of the user self-registration process after entering a usercredential at a prompt presented at the corresponding userself-registration page, and wherein the corresponding self-registrationverification process allows the user credential entered at the promptpresented at the corresponding user self-registration page to beverified redirection.
 20. The computing system according to claim 17,wherein the corresponding interview-based log in page is for a web site,an application or a service offered by that particular service providerthat is provided by an application platform of a cloud-basedmulti-tenant system; wherein the type of log in prompt accepts one of:an email address of the user, a telephone number of the user, a socialsecurity number of the user, or another unique identifier for the user;and wherein the type of authentication mechanism includes one or moreof: a prompt for a password, a prompt for a one-time-password orpasscode sent to the user via text message or via email message, aredirection to an identity provider for authentication, and a prompt fora biometric input by the user.